fix(uipath-maestro-flow): assert one project after scaffold, and stop the task demanding two

[rockymadden]

Stacked on #3090 → #3088. Retarget as those land.

Problem

skill-flow-bindings-no-duplicates failed on 2026-09-04 with all four structural criteria reporting the same thing:

FAIL: Multiple files found for '**/BindingsRegression*.flow':
  ['BindingsRegression/BindingsRegression/BindingsRegression.flow',
   'BindingsRegression/flow_files/BindingsRegression.flow']

The regression it exists to catch passed. No empty-keyed Connection bindings, no duplicate (name, propertyAttribute) rows, resourceKey matching the default. The bindings were clean. It failed on housekeeping, and the real result was invisible behind it.

Two causes, one on each side.

1. The skill checks the flow exists, never that it is the only one

cd does not persist between tool calls, so a later uip maestro flow init issued outside the solution auto-scaffolds <Project>Solution/ beside the real project rather than failing. Nothing downstream objects — flow validate passes on either file, format and node configure operate on whichever path they are handed. The duplicate surfaces only when something globs and resolves to two.

Step 2c now asserts it:

find . -name project.uiproj -o -name '*.flow' | sort   # expect exactly one of each

and says to delete the stray rather than mv it into place. Moving the auto-created project leaves the original where it was, which is exactly how this run ended up with two files that both validate.

SKILL.md rule #6 already said "finish with one project.uiproj; remove strays" — Step 2c is where that becomes checkable.

2. The task asked for a layout the skill forbids

The prompt demanded:

saved as BindingsRegression/flow_files/BindingsRegression.flow with BindingsRegression/project.uiproj

That is not the canonical <Solution>/<Project>/<Project>.flow, and it puts project.uiproj at the solution root instead of in the project directory. flow validate said so during the run — "does not match canonical" and "not registered as a project of solution".

So the agent scaffolded correctly, then hand-moved to satisfy the prompt, which is the one thing Step 2c tells it not to do. The task set up the failure the skill then got blamed for.

The layout was never load-bearing for a bindings regression, so the prompt now asks for the canonical one. The checker glob **/BindingsRegression*.flow matches it unchanged.

Verification

• 775 pytest pass.
• Glob still resolves the canonical path.
• The prompt keeps its actual subject: "Configure the connector node exactly once. Do not invoke any refresh schema workaround afterwards."
• All maintenance checkers clean apart from the anchor pre-existing on main; both flavors compose.

Note

This is the one of the eight nightly failures where the skill was already right and the eval was wrong. Worth flagging as a pattern: a task that asks for something the skill forbids will produce a failure that reads as a skill defect.

🤖 Generated with Claude Code

[github-actions]

Claude finished @rockymadden's task in 2m 43s —— View job

---

PR Review: fix(uipath-maestro-flow): assert one project after scaffold

• Read review criteria and project conventions
• Read full diff
• Read changed files in full context
• Run skill-specific checks
• Post review findings

---

Summary

Adds a post-scaffold uniqueness assertion (Step 2c in greenfield.md) that catches stray <Project>Solution/ auto-scaffolds, and fixes the test task prompt to request the canonical double-nested layout instead of a non-canonical one the skill forbids. Both changes are well-scoped and address real nightly failures.

Change-by-Change Review

1. skills/uipath-maestro-flow/references/author/greenfield.md (+8 lines)

Severity: Low

The new "assert it is the only one" paragraph is correctly placed inside the `` block, before the closing marker. The find command is practical and copy-paste ready. The instruction to delete (not `mv`) is sound — good anti-pattern callout.

One consistency issue: line 201 states cd does not persist between tool calls, but line 135 in the same file says the opposite:

Bash session state persists across tool calls. This cd is not scoped to one Bash invocation — your cwd remains inside <SolutionName>/ for every subsequent Bash call until you cd somewhere else.

The failure scenario is real (a stray scaffold does get created when flow init runs outside the solution), but the stated cause contradicts text 66 lines earlier. The stray more likely results from the agent breaking the && chain (issuing flow init in a separate Bash call without re-issuing cd), or from a retry after an error that resets the cwd, rather than cd not persisting. Consider tightening the causal claim — e.g. "if the && chain is broken or the cwd resets between calls" — so it doesn't contradict the existing session-state note. Fix this →

No other issues — the find command, the link to shared/file-format.md, and the rule #6 reference all check out.

2. tests/tasks/uipath-maestro-flow/bindings/no_duplicate_connection_bindings.yaml (+2/-2)

Severity: OK

The prompt now asks for the canonical BindingsRegression/BindingsRegression/BindingsRegression.flow layout instead of the non-canonical BindingsRegression/flow_files/BindingsRegression.flow. The existing checker glob **/BindingsRegression*.flow matches the canonical path unchanged. The rest of the task file (success criteria, weights, post_run cleanup) is untouched and correct.

What's Missing

Nothing identified.

Area Ratings

Area	Status	Notes
Frontmatter	OK	No frontmatter changes
E2E Tests	OK	Existing task updated; criteria and glob still match canonical path
Skill Body	OK	No SKILL.md changes
References & Assets	OK	greenfield.md change is inside the correct flavor block; all links resolve
Repo Hygiene	OK	No secrets, no cross-skill refs, changes scoped to one skill

Issues for Manual Review

• The cd persistence contradiction (line 135 vs. 201 in greenfield.md) is a clarity/consistency nit, not a functional blocker — the find check and "delete the stray" instruction are correct regardless of what caused the duplicate.
• The studioweb flavor has no project-creation override, so the canonical change applies cleanly — but confirm the find command works in Studio Web's sandbox if that environment restricts filesystem access.

Conclusion

Clean PR. The test task fix is correct and the new scaffold-uniqueness assertion operationalizes a rule (#6) that was previously stated but not checkable. One low-severity wording inconsistency about cd persistence — worth a quick fix but not blocking.

[github-actions]

Claude finished @rockymadden's task in 3m 1s —— View job

---

Coder-eval task lint (advisory)

1 task YAML changed; verdicts: 0 Critical, 0 High, 1 Medium, 0 Low, 0 OK.

Rubric: .claude/commands/lint-task.md. This check is advisory and never blocks merge.

Evidence of passing run

❌ High — PR body does not claim the modified task has been run through coder-eval and passed. "775 pytest pass" covers the unit/integration test suite, not a coder-eval execution of skill-flow-bindings-no-duplicates. Please edit the PR description to add a line like: Ran skill-flow-bindings-no-duplicates locally and it passed.

Per-task lint

tests/tasks/uipath-maestro-flow/bindings/no_duplicate_connection_bindings.yaml — verdict: Medium

Issues:

• [Medium] Validate-only flow tests miss correctness (line 11): tier is integration and no command_executed criterion matches flow\s+debug. By the rubric, integration-tier flow tasks without flow debug are Medium. In practice, this is a binding-structure regression test — flow debug would not validate binding correctness — so the gap is academic for this task's purpose.

Suggested fixes:

• Consider adding an explicit rationale to the description field (e.g. "validate-only: flow debug does not exercise binding structure") to earn the description-rationale carve-out (downgrades Medium → Low per rubric).

Notes:

• Self-report anti-pattern: OK — criteria use check_bindings.py against the actual .flow artifact.
• Prompt over-specification: OK — prompt states the goal and canonical layout (ground-truth anchor for the glob); node configure constraint is load-bearing for the regression, not procedure leaking.
• Meaningful coverage: OK — 5 run_command criteria with check_bindings.py check structure, empty stubs, duplicates, default matching, and bindings_v2 artifact. Strong mix.
• Could pass for the wrong reason: OK — criteria parse actual .flow JSON produced by the CLI; can't be faked without running node configure.
• Near-duplicate: OK — siblings (reconfigure_different_connection, multi_connector_independence, idempotent_reconfigure) share the check_bindings.py scaffold but test materially distinct operations (A→B swap, cross-connector independence, idempotent re-run vs. single-configure correctness).
• CLI verb reachability: Skipped — scripts/check-cli-verbs.py could not run (missing permission). Please run locally: python3 scripts/check-cli-verbs.py --json tests/tasks/uipath-maestro-flow/bindings/no_duplicate_connection_bindings.yaml.
• Redundant/pinned uip CLI: OK — no sandbox.node.env_packages.
• Run-limit fields under agent: OK — no agent: block.

Within-PR duplicates

• No duplicate clusters detected (only 1 task YAML changed).

Conclusion

• ⚠ 1 task has issues, max severity Medium (validate-only axis). Advisory only — not blocking merge. Separately, please add a passing-run claim for the modified task to the PR description.

---