implement

Implement

You are tasked with implementing an approved technical plan from .rpiv/artifacts/plans/. These plans contain phases with specific changes and success criteria.

Input

$ARGUMENTS

The input above is <plan-path> [phase]:

• First token is the plan path under .rpiv/artifacts/plans/.
• Anything after it (e.g. "Phase 2") names a single phase to scope to.

Rules:

• If a phase is named → single-phase (sequenced lane) mode. Phases run sequentially, in the plan's dependency order, so every earlier phase has already landed its files — your prerequisites are present in the working tree. Implement ONLY the named phase, touching only the files that phase owns. Hard rules for this mode:
  • Never implement, create, or edit another phase's files — not even if one is missing. You are one unit of a sequenced run; back-filling another phase's work duplicates it and corrupts the next lane.
  • A genuinely missing prerequisite is a hard error, not a decision. If a file your phase must read or edit (one an earlier phase owns) is absent, STOP and fail with prerequisite missing: <path> (expected from an earlier phase). Do not create it, do not ask_user_question about it, and do not defer your own edits — fail loudly so the run surfaces the ordering defect.
  • Never silently defer your phase's own edits. Apply every change the named phase owns, or fail. A phase that writes a partial slice and checks off nothing is worse than a clean failure.
  • Repo-located scratch lives under .rpiv/tmp/, nowhere else. Any file you create that is not in your phase's files: — a probe script, a fixture, a captured payload — goes under .rpiv/tmp/ (exempt from the workflow's scope floor) or outside the repo entirely. The floor counts untracked files too (git status -uall): a scratch file left at the repo root or in an undeclared directory is an undeclared write the downstream implement-scope-check flags. Delete repo-located scratch when you're done with it regardless.
  • Do not read, edit, or check off other phases' sections. Stop and print the closing block as soon as the named phase's own success criteria pass.
  • Record a #### Reconciliation directive for cross-phase test updates you can't apply yourself. Under build/vet's parallel implement lane, a correct change in YOUR phase can invalidate a test expectation that lives in a SIBLING phase's landed section — and single-phase mode forbids editing another phase's files. Do NOT edit the sibling's file and do NOT silently skip it: record a #### Reconciliation directive in your OWN phase's section. The directive is a machine-findable, machine-applicable find → replace against a single repo-root-relative target, so the downstream reconcile stage can apply it write-restricted to the plan's declared write-set:

    #### Reconciliation
    - `path/to/x.test.ts`: replace `expect(r).toBe(3)` → `expect(r).toBe(4)` — <one-line rationale>
    

    The find/replace spans may span multiple lines, but must carry no inner backticks — the spans are backtick-delimited, so a snippet containing a backtick (a template literal, markdown-in-a-test) is inexpressible in this form. For such content use the fenced form: the same - : replace — <rationale> header with NO inline spans, followed by a find: line + a fenced code block, then a replace: line + a fenced code block (indent the blocks under the list item; the fence line's own indentation is stripped from the captured content):

    #### Reconciliation
    - `path/to/x.test.ts`: replace — <one-line rationale>
      find:
      ```
      const s = `a ${b} c`;
      ```
      replace:
      ```
      const s = `a ${b} c d`;
      ```
    

    The target MUST be in the plan's declared write-set — the union of every phase's files:, twin-expanded (x.ts licenses x.test.ts) — the same authority the scope floor enforces; eligibility is plan-derived, never a filename convention, so any language's test or expectation file qualifies once declared. reconcile rejects (and reports) a directive against an undeclared path — route such an edit through validate's remediation arm or the owning phase. Record directives only for MECHANICAL expectation/consistency updates you can state concretely; a real logic change in a sibling's files is plan-level work (/skill:revise), not a reconciliation directive.