Planner becomes the sole case-SDD author

CODEOWNERS

@@ -73,6 +73,14 @@
 # Planner skill (PDD → SDD design + multi-skill task planning)
 /skills/uipath-planner/ @RaduAna-Maria @abhiram-vad
 /tests/tasks/uipath-planner/ @RaduAna-Maria @abhiram-vad
+# Case-design evals migrated from uipath-maestro-case (planner-sole-SDD-author) — case owners stay reviewers
+/tests/tasks/uipath-planner/_shared/ @RaduAna-Maria @abhiram-vad @charlesliu9 @song-zhao-25 @jundayin
+/tests/tasks/uipath-planner/case_design_interview/ @RaduAna-Maria @abhiram-vad @charlesliu9 @song-zhao-25 @jundayin
+/tests/tasks/uipath-planner/case_design_loan/ @RaduAna-Maria @abhiram-vad @charlesliu9 @song-zhao-25 @jundayin
+/tests/tasks/uipath-planner/case_finalize_draft/ @RaduAna-Maria @abhiram-vad @charlesliu9 @song-zhao-25 @jundayin
+/tests/tasks/uipath-planner/case_finalize_draft_loan/ @RaduAna-Maria @abhiram-vad @charlesliu9 @song-zhao-25 @jundayin
+/tests/tasks/uipath-planner/case_finalize_draft_picker/ @RaduAna-Maria @abhiram-vad @charlesliu9 @song-zhao-25 @jundayin
+/tests/tasks/uipath-planner/case_finalize_draft_reject/ @RaduAna-Maria @abhiram-vad @charlesliu9 @song-zhao-25 @jundayin
 
 # Solution skill (uip solution lifecycle)
 /skills/uipath-solution/ @UiPath/team-merlot @UiPath/team-orange

skills/uipath-maestro-case/references/brownfield.md

@@ -1,6 +1,6 @@
 # Brownfield — Edit an Existing Case
 
-Targeted changes to an existing `caseplan.json`. Skips the Phase 0–6 build pipeline. Terminates at `validate`, then hands off to Phase 5 (debug) / Phase 6 (publish).
+Targeted changes to an existing `caseplan.json`. Skips the design delegation and the Phase 1–6 build pipeline. Terminates at `validate`, then hands off to Phase 5 (debug) / Phase 6 (publish).
 
 > **Greenfield (new case from `sdd.md`) uses a different journey.** If `caseplan.json` does not yet exist, or the user wants to (re)build from a spec, see [planning.md](planning.md) → [implementation.md](implementation.md) → [phased-execution.md](phased-execution.md) instead.
 

skills/uipath-maestro-case/references/implementation.md

@@ -14,6 +14,8 @@ Execute the `tasks.md` plan, building `caseplan.json` via direct JSON edits per
 
 Every plugin uses direct JSON writes via its `impl-json.md`. Cross-cutting mechanics (ID generation, Pre-flight Checklist, primitive ops, the canonical write contract) are in [case-editing-operations.md](case-editing-operations.md).
 
+> **Read each `impl-json.md` once per plugin type, not per T-entry.** Group the section's T-entries by plugin, read that plugin's `impl-json.md` a single time, then execute every T-entry of that type from the one read (this is what the per-section batch write contract already assumes). Re-opening a plugin reference per T-entry is a read-budget defect — observed at up to 26 re-reads of one `impl-json.md` in a single build, each costing a full inference round-trip. After context compaction, re-read only the plugin for the section in progress.
+
 **Per-section batched writes — mandatory.** Process `tasks.md` one **section** at a time (§4.2.1 vars, §4.3 triggers, §4.4 stages, §4.6 task-shapes, §9.7 connector schema, §9.8 I/O binding, §10 conditions, §11 SLA):
 
 1. **One Read** of `caseplan.json` at section entry.

skills/uipath-maestro-case/references/phased-execution.md

@@ -77,7 +77,7 @@ uip maestro case validate "<caseplan.json path>" --skeleton --output json
 
 ### Phase 2 hard stop
 
-**Gated by the up-front build-review preference (SKILL.md Rule 11) — never a mid-build surprise.** The preference was captured at journey start: the final design confirmation on the interview journey, the single post-roadmap question on the provided-SDD journey. Always print the §Summary content below, then branch:
+**Gated by the up-front build-review preference (SKILL.md Rule 11) — never a mid-build surprise.** The preference was captured at journey start: the delegated design's Case Review Build options on the greenfield journey, the single post-roadmap question on the provided-SDD journey. Always print the §Summary content below, then branch:
 
 - **Straight-through** → continue directly into Phase 3 with no prompt; the summary doubles as the milestone narration line.
 - **Pause-at-preview** → present the §Prompt below; only a user response transitions out of Phase 2.
@@ -153,6 +153,8 @@ Never trust in-memory maps from Phase 2 without re-reading `caseplan.json` — c
 
 ### Phase 3 — Execution order
 
+> **In-session schema memo.** `tasks describe` / `case spec` results fetched this session are carried forward — in memory and in their persisted artifacts (`tasks/registry-resolved.json`, `tasks/spec-cache.<elementId>.json`, `tasks/trigger-spec-cache.json`). NEVER re-run an identical describe/spec call this session (same type + id): re-read the persisted artifact instead. Observed failure: the same 5-type `tasks describe` set re-ran verbatim 12m45s later, costing ~2–4 minutes and redundant turns per build.
+
 After re-entry:
 
 1. **Connector task detail** — for each connector task in `tasks.md`, run plugin's `impl-json.md` detail steps: `case spec --type {activity,trigger} --input-details`, then mint `data.context[]` / `data.inputs[]` / `data.outputs[]` from the populated `caseShape` (placeholder substitution + var/id minting).
@@ -181,9 +183,13 @@ On success: `{ Result: "Success", Code: "CaseValidate", Data: { File, Status: "V
 
 On failure: output lists `[error]` and `[warning]` entries with path and message. Fix reported issues (usually via targeted re-run of earlier step) and re-run `validate`.
 
+### Validate-loop guard — no re-validate without an intervening edit
+
+**Never re-run `uip maestro case validate` unless `caseplan.json` (or a sidecar it validates) changed since the last run.** A validate that follows another validate with zero edits in between is a no-op that costs a full CLI round-trip and a turn — observed worst case: 20 validates in one session, 14 of 19 re-runs with no intervening edit, 36% of wall clock. The guard applies in every phase: Phase 2's informational validate runs once, Phase 4's authoritative validate runs once per fix. Fix → edit → validate is the only legal loop shape; validate → validate is a defect.
+
 ### Retry policy
 
-Up to **3 validation retries** per session. After 3rd failure, halt and ask user with **AskUserQuestion**: show remaining errors and options:
+Up to **3 validation retries** per session — each retry MUST be preceded by a fix edit (validate-loop guard above). After 3rd failure, halt and ask user with **AskUserQuestion**: show remaining errors and options:
 
 - `Retry with fix` — agent attempts fix, re-runs validate (counter does not reset).
 - `Pause for manual edit` — exit skill mid-flight; user edits `caseplan.json` directly and re-runs skill.