feat(api-workflow): teach connector-event triggers

[rares-baesu-uipath]

What

Teaches the uipath-api-workflow skill how to start a workflow from a connector event (a Slack button click, a new Outlook calendar entry, a new Salesforce record). The skill previously had no guidance for this and actively told agents that triggers could not be authored at all.

Two commits — the first is an unrelated sanitization fix, kept separate for review.

The fact this guidance exists to convey

A trigger is an activity with call: "UiPath.IntSvcEvent" placed first in the root sequence, and a matching "EventTrigger" entry in bindings_v2.json. That entry is what registers the Orchestrator event trigger on deploy.

Omit it and the workflow validates, packs, publishes and deploys cleanly — and then never fires. Every gate reports success, so nothing else catches it. That silent failure is the most expensive mistake in this area and is what the new rule, the guide and the offline test all point at.

Added

• references/trigger-authoring-guide.md — discovery flow, the activity shape, the EventTrigger binding contract, JMESPath filter composition, and what polling vs webhooks means for a local run
• Critical Rule 16a, a When-to-Use entry, and reference/template navigation
• assets/templates/trigger-workflow-template.json — passes uip api-workflow validate
• Two coder-eval tasks: an offline edit task that grades the stale-binding trap, and an authed e2e that grades the full authoring path

Corrected

• Two now-stale claims that trigger activity types cannot be stubbed
• A retired CLI verb: solution resource refresh → solution resources refresh (retired at uip 1.196.0), including one pre-existing occurrence

Studio Web flavor

Studio Web derives the binding itself and cannot run the local CLI write commands, so the bindings and local-run passages are enclosed in flavor blocks with sparse overrides.

Worth a look during review: the flavor contract test swept a fixed list of built references that excluded any new file, so the new reference initially leaked CLI-only guidance into the Studio Web build with nothing to catch it. The new reference is now on that list, and the guard was checked to be non-vacuous (planting a banned command in the canonical guide fails the test).

Verification

• skills:validate, skills:check-links (6866 links), check-skill-status, check-skills-sh, check-cli-verbs — all OK
• flavor contract suites: 50/50
• template re-validated: "Status": "Valid"
• the offline task was checked to discriminate correctly: it fails on the unsolved seed, fails on the trap where only the workflow is edited and the binding is left stale, and passes when both artifacts are updated
• skills:test Update coded skill to use uipcli instead of rpa-tool #20 (pack builds complete…) fails here, but it fails identically on a clean tree — pre-existing, unrelated

Dependency

Requires the matching uip CLI support (registry resolve --kind trigger, registry stub for trigger types, bindings sync EventTrigger generation) — UiPath/cli#4365. That should merge and ship first: the e2e task drives the real CLI and cannot pass against a published build without --kind. The offline task is unaffected.

🤖 Generated with Claude Code