feat(uipath-maestro-case): wire connector-activity to case spec --input-details#592
feat(uipath-maestro-case): wire connector-activity to case spec --input-details#592song-zhao-25 wants to merge 5 commits intomainfrom
case spec --input-details#592Conversation
|
Claude finished @song-zhao-25's task in 3m 43s —— View job PR Review:
|
| Area | Status | Notes |
|---|---|---|
| Frontmatter | OK | SKILL.md frontmatter unchanged; name matches folder |
| E2E Tests | Issue | No test YAML for the new case spec workflow (Medium — consistent with existing gap) |
| Skill Body | OK | Rule 10 update is correct and minimal |
| References & Assets | Issue | Personal paths in .maintenance/ doc and impl-json.md; cache path inconsistency in planning.md; unresolvable external repo links |
| Repo Hygiene | Issue | Personal filesystem paths committed (3 in .maintenance/, 1 in impl-json.md) |
Duplication Assessment
The reference-pointer discipline is generally good. Cross-skill content (filter trees, reference resolution, connections) is linked to uipath-platform rather than restated. Within the skill, some content appears in both connector-integration.md and planning.md (connection-scoped warning, pagination note, filter anti-pattern), but these are single-sentence warnings appropriate for both the top-level reference and the plugin-level guide — borderline acceptable.
Issues for Manual Review
- CLI correctness: Cannot verify that
uip maestro case spec --type activity --activity-type-id <id> --connection-id <id> --skip-case-shape --output jsonis the exact CLI syntax. The PR states this is shipped onfeat/connector-task-specin the uipcli repo. caseShapestructure accuracy: Cannot verify the exact shape ofcaseShape.context[](8-entry array with{{CONN_BINDING_ID}}/{{FOLDER_BINDING_ID}}placeholders) matches the CLI's actual output.essentialConfigurationround-trip: The Known Limitations note says the FE may not render certain fields — confirm this is acceptable for the target use case (Studio Web re-rendering).
Conclusion
Request changes — two actionable items to fix before merge:
- High: Remove personal filesystem paths from
.maintenance/case-spec-cli-migration-plan.md(3 instances of/Users/song.zhao/...) andimpl-json.mdline 217 (~/Documents/knowledge/...). Per repo rules, no personal paths in committed files. - Medium: Fix cache path in
planning.md:21—~/.uip/should be~/.uipcli/to match the rest of the skill (pre-existing but touched in this PR).
The overall design is sound — collapsing three CLI calls into one, using cross-links instead of duplication, and cleanly separating activity (this PR) from trigger (PR 2).
…history Remove `.maintenance/case-spec-cli-migration-plan.md` — a maintainer-only planning doc that captured the case-spec CLI migration approach + the file-by-file deltas. Activity migration shipped in PR #592 (this branch); trigger migration is the explicit subject of PR 2 and will be re-planned in its own branch when we get there. Net effect was unloaded prose drift: the doc was already updated for each CLI surface change (`--skip-case-shape` → `--sections`, spec-input-details vendoring), so it carried real upkeep cost without runtime value. The work it described is preserved in: - This branch's commits (`46b835ce` activity-first migration, `59a1afba` --sections adoption, `8396312d` doc vendoring, `041bcf4c` filter-content trim). - PR #592's description. Recoverable from git history if useful for PR 2 planning.
Migrate the uipath-maestro-case skill's connector-activity task from the legacy `is resources describe` + `case tasks describe` flow to the new `uip maestro case spec` command (uipcli PR #1519). Two named section bundles defined: - PLANNING_SECTIONS = identity,operation,connection,inputs,outputs,filter,webhook,references - IMPLEMENTATION_SECTIONS = identity,connection,caseShape Phase 2 planning runs PLANNING_SECTIONS for the leaner payload (no caseShape, essentialConfiguration, diagnostics). Phase 3 implementation runs IMPLEMENTATION_SECTIONS with `--input-details` to mint the populated caseShape. `diagnostics` is opt-in; append `,diagnostics` when surfacing fallbacks to `build-issues.md`. ## Skill changes - `connector-activity/planning.md` — Step 3 uses PLANNING_SECTIONS; diagnostics opt-in noted. - `connector-activity/impl-json.md` — Phase 3 calls `case spec --input-details` with IMPLEMENTATION_SECTIONS, copies caseShape, mints var/id/elementId, syncs bindings_v2.json. Drops `is resources describe` re-fetch entirely. Adopts flow's hard-gate framing for required-field validation and FilterBuilder detection. - `connector-integration.md` — top-level rewrite establishing the case-spec-first contract; cross-links platform Filter Trees (CEQL) doc instead of restating CEQL. - `case-commands.md` — `case spec` flag table replaces `--skip-case-shape` with `--sections`, with bundle definitions and diagnostics opt-in spelled out. - `case-spec-input-details.md` — vendored input-details contract into the skill (was previously only in the case-tool package). - `SKILL.md` Rule 10 — `case spec` for connector tasks; `case tasks describe` stays for non-connector tasks. ## Cleanup - Drop `.maintenance/case-spec-cli-migration-plan.md` (work captured in this PR's history). Trigger plugins remain on the legacy path until a follow-up PR. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fe0acf9 to
d4a3968
Compare
…`case spec`
Migrate trigger plugins (in-stage `wait-for-connector` task and case-level
event trigger) from the legacy `get-connection` + `case tasks describe
--type connector-trigger` / `is triggers describe` two-call pattern to a
single `uip maestro case spec --type trigger` call per phase, mirroring
PR 1's activity migration.
The CLI's `buildTriggerCaseShape` + `buildTriggerContext` emit the
FE-canonical inputs / outputs / context with placeholders the skill
substitutes at write-time:
- `{{CONN_BINDING_ID}}` → minted connection binding id
- `{{FOLDER_BINDING_ID}}` → minted folder binding id (when present)
- `{{TRIGGER_REGISTRATION_KEY}}`→ minted eventTriggerKey
(`<connection-id>_<startNode.id>` per
FE `PackagingUtil.ts:227`); only present
when the trigger has event parameters
`--input-details.filter` writes all three trigger filter sinks at once:
the FilterTree in `essentialConfiguration.filter` (design-time round-trip),
the compiled JMESPath in `activityPropertyConfiguration.filterExpression`
(FE projection), and the runtime expression in `body.filters.expression`.
## What changes
- `references/connector-trigger-common.md` — major rewrite. Planning
Pipeline collapses 7 → 7 (renumbered, but Step 3 swaps `is triggers
describe` for `case spec --type trigger --sections <PLANNING_SECTIONS>`).
Implementation section drops the 2-step shared metadata fetch +
shared metadata construction (context array, metadata body,
essentialConfiguration, input body — all CLI-built now). Replaced with
a 5-step Phase 3 flow: build input-details → run case spec → mint
binding ids + trigger registration key → substitute placeholders →
mint var/id/elementId. Cross-link platform Filter Trees (CEQL),
reference resolution, and connections (PR 1 patterns inherited).
- `connector-trigger/planning.md` — refresh ref to common pipeline
(drop the "7-step" framing).
- `connector-trigger/impl-json.md` — collapse Steps 1-2 (legacy CLI)
into one `case spec` call. New Step 4 substitutes placeholders. Step 5
mints var/id/elementId. Step 6 writes the task with `serviceType:
"Intsvc.WaitForEvent"`. eventTriggerKey uses the case's startNode id
(NOT the stage id) per FE convention.
- `triggers/event/planning.md` — same ref refresh.
- `triggers/event/impl-json.md` — same Step 1-2 collapse for the
case-level trigger node. Trigger inputs get NO elementId (different
from in-stage task inputs); outputs get simplified shape (strip body /
target / set _jsonSchema: null) for the trigger node, with full body
schema flowing into `variables.inputOutputs[]` (Step 7). For event
triggers the eventTriggerKey uses the trigger node's own id.
- `references/implementation.md` — Phase 2 table: `case spec` is the
Phase 3 call; "Do NOT call case spec in Phase 2" replaces the longer
list of legacy commands.
- `references/phased-execution.md` — same Phase 2 update + Phase 3
re-entry step now mentions case spec instead of the legacy fetches.
Cross-skill cross-links inherited from PR 1 stay: filter-trees-ceql,
reference-resolution, connections (all from `uipath-platform`).
…-shape Follow-up to the CLI revert (uipcli `feat/connector-task-spec` / PR #1519): the case skill's --sections + PLANNING_SECTIONS / IMPLEMENTATION_SECTIONS bundle convention reverts to the binary --skip-case-shape flag the CLI now exposes. The bundle indirection didn't earn its complexity. The only meaningful saving was dropping caseShape during planning (~6-10K tokens for a typical Outlook activity); the granularity past "with-vs-without caseShape" wasn't load-bearing. --skip-case-shape captures ~90% of the saving with ~10% of the surface area. ## What changes - `connector-activity/planning.md` Step 3 — `--skip-case-shape` replaces the PLANNING_SECTIONS csv. Drops the diagnostics-opt-in note (no granular control any more). - `connector-activity/impl-json.md` Step 2 — Phase 3 call drops the IMPLEMENTATION_SECTIONS csv (just `--input-details` now). Step 3 required-field gate refs the lean planning spec via `--skip-case-shape`. - `connector-integration.md` — top-level case spec recipes revert to `--skip-case-shape` / `--input-details` pair. Output table `caseShape` row reverts to the `--skip-case-shape` framing. - `case-commands.md` — `--skip-case-shape` row replaces `--sections <csv>` row + bundle definitions. Returns description reverts. - `connector-trigger-common.md` — same revert across the planning pipeline (Step 3) and Phase 3 implementation (Step 2). Drops diagnostics-opt-in note + the references to PLANNING_SECTIONS / IMPLEMENTATION_SECTIONS. - `case-spec-input-details.md` (vendored doc) — validation-rule table + Discovery section revert. PR #592 retains the 2-commit shape (squashed activity migration + trigger migration); this revert lands on top as a third commit and can be folded into the squash before merge if desired.
…adoption Six post-review fixes across the activity + trigger migration: 1. Unify `data.typeId` / `data.connectionId` (camelCase) — replace kebab-case `data.type-id` / `data.connection-id` introduced in `connector-activity/impl-json.md` (lines 5, 184) and `connector-trigger/impl-json.md` (lines 5, 104). Matches the dominant repo convention in `implementation.md`, `skeleton-tasks.md`, `connector-integration.md`, `registry-discovery.md`. 2. Surface `case-spec-input-details.md` in SKILL.md Reference Navigation — the 331-line vendored doc was reachable via 7 transitive links but missing from the top-level "I need to..." nav table. 3. Add Step 3 Required-event-param hard gate to trigger plugins (`connector-trigger/impl-json.md`, `triggers/event/impl-json.md`), mirroring activity Step 3. Renumbers subsequent steps (3-8 → 4-9 for connector-trigger; 3-9 → 4-10 for event), updates internal step cross-references in JSON examples and Graceful Degradation tables, updates §6a/§6b → §7a/§7b and §7a → §8a in event plugin, updates the common-doc cross-link to match the new event Step 4 anchor. Both plugins' Graceful Degradation tables already mention the gate; this pairs the orphaned row with a numbered workflow step. 4. Update Post-Write item 10 in `connector-activity/impl-json.md` (and item 7 in `connector-trigger/impl-json.md`) to handle both v19 (`root.data.uipath.bindings[]`) and v20 (top-level `bindings[]`) binding paths — Rule 17/18 make v20 a real path. 5. Add per-plugin override note in `connector-trigger-common.md` for the `eventTriggerKey` `<connection-id>_<startNode.id>` formula — for case-level event triggers, `startNode.id` is the trigger node's own id, not the case start node id. 6. Fix broken anchor link in `connector-activity/impl-json.md:57` — `#mutual-exclusion-with---skip-case-shape` was not a heading in `case-spec-input-details.md`. Re-link to `§ Validation rules` where the mutual-exclusion rule lives. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Follow-up to 62121cf — the Phase 2 connector-task shape row in the "Tasks" table referenced `data` keys in kebab-case. JSON keys are camelCase per implementation.md:92 and the plugin impl-json.md docs. Tasks.md field-name occurrences in column 2 stay kebab. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
connector-activityplugin from the legacycase tasks describe+is resources describetwo-call dance to the unifieduip maestro case speccommand (CLI shipped on uipclifeat/connector-task-spec).input-values+filterthroughcase spec --input-details, reading the populatedcaseShape, substituting{{CONN_BINDING_ID}}/{{FOLDER_BINDING_ID}}placeholders with minted ids, and droppingcaseShape.{context, inputs, outputs}straight intocaseplan.json.uipath-maestro-flow'sconnectorplugin: cross-linkuipath-platformfor filter-trees-ceql / reference-resolution / connections rather than restate; adopt flow's Step-5 hard gate + Step-6a FilterBuilder detection wording.connector-trigger,triggers/event) are intentionally out of scope here — they follow in PR 2.What's wired
connector-activity/planning.mdcase spec --skip-case-shapefor required-field discovery, references with pre-built discoverCommand, and filter contract.connector-activity/impl-json.mdcase spec --input-detailscall → placeholder substitution → mint var/id/elementId → write task. Drops the legacyis resources describere-fetch.SKILL.mdRule 10case spec; non-connector tasks viacase tasks describe.connector-integration.mdregistry-discovery.mdcase specis the unified post-pull endpoint for connector tasks.implementation.mdcase spec.case-commands.mdcase specsection above the existingcase tasks describe(which stays for non-connector tasks).skeleton-tasks.mdcase specfor connector tasks.references/evals/evals.json.maintenance/case-spec-cli-migration-plan.md(NEW)Test plan
essentialConfigurationround-trip on a real Outlook 365 Send Email task — confirm Studio Web re-renders cleanly.🤖 Generated with Claude Code