renovate-orchestrator

name	renovate-orchestrator
description	Use when starting or resuming a legacy web modernization (UI/UX and/or backend) — routes between renovation phases, tracks state in plan.md, and enforces the harness/test/review gates. Entry point for the harness-driven-renovate workflow.

Renovate Orchestrator

Entry point for a harness-driven legacy renovation. You do not do the phase work yourself — you decide which phase skill to invoke next, record state, and refuse to let destructive work happen before its gate is satisfied.

When to use

• The user asks to modernize / refactor / renovate a legacy web system (frontend, backend, or both).
• The user asks to "continue" a renovation already in progress.

First action: establish state

Create or read plan.md in the working directory (or session state) with this block:

## Renovation State
target: <system name, e.g. nMIMO>
goal_level: 30            # 30 | 60 | 100
phase: discovery          # discovery|arch|grilling|harness|ux|backend|ai|impact
gates:
  grilling: pending       # pending | passed
# Harness is tracked PER SEAM, not globally — a global "passed"
# would let later work touch a new, unpinned seam (loophole).
harness:
  # <seam/capability>: pending | green
  # Populate only after architecture-recovery identifies real seams.
# Per-change evidence for the test & review gates, so a resumed
# session can tell whether an in-flight change actually passed them.
changes:
  # - id: <change-id>
  #   touched_seams: [<architecture-recovered-seam-id>]
  #   mode: design | code
  #   figma_design: not_used | requested | changes_requested | approved
  #   # optional Figma path; not_used only if no Figma review was requested
  #   # and no Figma URL/frame/baseline is claimed
  #   tests: pending | passed        # test-authoring gate
  #   web_action: pending | passed   # web-action-testing gate for UX code
  #   azure_architecture: pending | passed # azure-backend-architecture gate for backend code
  #   review: pending | passed       # strict-code-review gate
  #   harness_regression: pending | passed

If it does not exist, start at phase: discovery, grilling: pending, and an empty harness map. Only architecture-recovery may populate it from evidence in the real target repository. Never reuse example seam names from another system: they can falsely authorize code changes against an unpinned target seam.

Routing table

Current phase	Gate satisfied?	Invoke next
discovery	—	legacy-discovery (functional current state), then advance to arch
arch	—	architecture-recovery (technical current state + seams + target options), then advance to grilling
grilling	grilling gate must pass	requirements-grilling; on pass → harness
harness	per-seam harness must be green for seams the next phase touches	behavior-harness; on green → ux/backend
ux / backend (design mode)	grilling passed	ux-modernization / strangler-backend — analysis, wireframes, target architecture only; no code
ux (code mode)	harness green for every touched seam; Figma approved if review is requested or a Figma URL/frame/baseline is claimed	ux-modernization → optional figma-design-review → frontend-code-implementation → web-action-testing → strict-code-review
backend (code mode)	harness green, Azure architecture passed, and an approved reversible slice	azure-backend-architecture → strangler-backend → backend-slice-implementation → strict-code-review
ai	ux/backend underway; design vs code same rule as above	ai-augmentation
impact	requires changes shipped	impact-measurement

Design mode vs code mode

A 30-level engagement is largely design-only. Split the work:

• Design mode (analysis, wireframes, target architecture, AI use-case specs) is allowed after the grilling gate, before the harness exists.
• Code mode (implementing, deleting, cutting over, changing behavior) requires the harness green for every seam the change touches, plus the test and review gates.

This resolves the apparent conflict where level-30 lists UX/backend/AI work before the harness: that work is design mode; harness is only required to write code.

Gate enforcement (non-negotiable)

digraph gates {
  "grilling gate" [shape=diamond];
  "code mode? (implement/delete/cutover)" [shape=diamond];
  "harness green for touched seams?" [shape=diamond];
  "Figma review requested or baseline claimed? (UX code only)" [shape=diamond];
  "Requested Figma review approved?" [shape=diamond];
  "Azure backend gate? (backend code only)" [shape=diamond];
  "test gate: tests written first?" [shape=diamond];
  "web-action gate? (UX code only)" [shape=diamond];
  "review gate: strict-code-review passed?" [shape=diamond];
  "proceed / mark done" [shape=box];
  "STOP - run required skill first" [shape=box];

  "grilling gate" -> "STOP - run required skill first" [label="ambiguous reqs"];
  "grilling gate" -> "code mode? (implement/delete/cutover)" [label="reqs crisp"];
  "code mode? (implement/delete/cutover)" -> "proceed / mark done" [label="no (design only)"];
  "code mode? (implement/delete/cutover)" -> "harness green for touched seams?" [label="yes"];
  "harness green for touched seams?" -> "STOP - run required skill first" [label="any seam pending"];
  "harness green for touched seams?" -> "Figma review requested or baseline claimed? (UX code only)" [label="all green"];
  "Figma review requested or baseline claimed? (UX code only)" -> "Requested Figma review approved?" [label="UX code + requested/claimed"];
  "Figma review requested or baseline claimed? (UX code only)" -> "Azure backend gate? (backend code only)" [label="not UX or not_used with no request/baseline"];
  "Requested Figma review approved?" -> "STOP - run required skill first" [label="requested/changes_requested"];
  "Requested Figma review approved?" -> "Azure backend gate? (backend code only)" [label="approved"];
  "Azure backend gate? (backend code only)" -> "STOP - run required skill first" [label="backend code + not passed"];
  "Azure backend gate? (backend code only)" -> "test gate: tests written first?" [label="passed or not backend"];
  "test gate: tests written first?" -> "STOP - run required skill first" [label="no"];
  "test gate: tests written first?" -> "web-action gate? (UX code only)" [label="yes"];
  "web-action gate? (UX code only)" -> "STOP - run required skill first" [label="UX code + not passed"];
  "web-action gate? (UX code only)" -> "review gate: strict-code-review passed?" [label="passed or not UX"];
  "review gate: strict-code-review passed?" -> "STOP - run required skill first" [label="no"];
  "review gate: strict-code-review passed?" -> "proceed / mark done" [label="yes"];
}

• Never run frontend-code-implementation, backend-slice-implementation, ux-modernization, strangler-backend, or ai-augmentation in code mode while any touched seam is harness: pending. Check the seam list the change declares against the harness map; if any is not green, stop and run behavior-harness for that seam first.
• Never mark a code change done without recording, in plan.md's changes entry, that tests: passed (from test-authoring) and review: passed (from strict-code-review), plus harness_regression: passed.
• If a UX change opts into Figma review (figma_design: requested or changes_requested) or claims a Figma URL/frame as its implementation baseline, do not start UX code mode until figma_design: approved is recorded from figma-design-review. Figma URL/frame ID, open comment status, approver, and approval time must be recorded for opted-in/baseline-claimed changes. If the change does not use Figma and does not claim a Figma baseline, record figma_design: not_used and continue through the mandatory harness, test, web-action, and review gates.
• Never mark UX code done without web_action: passed from web-action-testing. Real browser action Blocker/Major findings must be closed or explicitly accepted.
• Never start backend code mode without azure-backend-architecture evidence: Azure service choices, Well-Architected tradeoffs, security/network/identity constraints, observability, rollback, and Azure tooling gaps.
• Behavior-change protocol: if a change intends to alter pinned behavior (e.g. removing a dead feature, a strangler cutover), the golden master may be updated only with an explicit, requirement-linked, user-approved behavior-change entry — see behavior-harness and strict-code-review. Never edit fixtures just to make a drifting test pass.

Direct-invocation safety

Gates only bind if this orchestrator runs. The phase skills (ux-modernization, frontend-code-implementation, figma-design-review, azure-backend-architecture, strangler-backend, backend-slice-implementation, ai-augmentation) are therefore required to verify state as their first action (read plan.md, check grilling + touched-seam harness, requested Figma approval for UX code, plus Azure evidence for backend code) and route back here if a gate is unmet. If you are invoked after a phase skill already started code work without that check, stop and reconcile state before continuing.

Cross-cutting skills

test-authoring, figma-design-review, web-action-testing, azure-backend-architecture, and strict-code-review are not phases — invoke them inside any phase that needs them. frontend-code-implementation and backend-slice-implementation perform actual code-mode edits after their respective design phases. test-authoring and strict-code-review apply to all code changes; figma-design-review applies before UX code mode only when Figma review is requested or a Figma baseline is claimed; web-action-testing applies to UX prototypes/code slices after implementation; azure-backend-architecture applies before backend code mode and whenever Azure service choices change.

After each phase

Update plan.md (phase, gates.grilling, the per-seam harness map, and the relevant changes entry), then tell the user what phase completed and what runs next. Scale ambition to goal_level (30/60/100 — see each skill).

Output template and helper script

• Korean template: OUTPUT_TEMPLATE.md
• Scaffold script: scripts/create-plan.sh <repo-root> <target-name>