devlyn-cli 4.1.0 → 4.2.0

package/config/skills/devlyn-resolve/references/phases/cleanup.md

@@ -1,33 +0,0 @@
-# PHASE 4 — CLEANUP (canonical body)
-
-The selected IMPLEMENT worker performs code/doc cleanup in its existing invocation before its final checks. The owner then uses the CLEANUP span for generated-artifact removal and invariant checks only; no new model call.
-
-<input>
-- Cumulative diff, original spec and immutable PLAN authorized surface.
-- CLEANUP `pre_sha`: tracked source and HEAD must remain unchanged during owner checks.
-</input>
-
-<allowlist>
-Within IMPLEMENT and PLAN authorization, you may modify or delete:
-
-1. **Tooling artifacts** the spec did not list as deliverables: `test-results/`, `playwright-report/`, `.last-run.json`, coverage HTML output, build artifacts, runtime caches (`__pycache__/`, `*.pyc`, `.cache/`).
-2. **Dead code added by this diff** — symbols (functions, classes, types, exports) introduced by this diff that no other code added by this diff references AND that are not part of the spec's required surface. Pre-existing dead code is out of scope.
-3. **Doc references this diff invalidated** — links / file paths / symbol names in markdown files that this diff renamed or removed. Update only the references; do not rewrite surrounding prose.
-4. **Inline comments** that explain code this diff deleted but the comment still mentions.
-
-Files outside this allowlist must not change. Pre-existing tooling leaks (already in main before this run) belong to a future cleanup, not this one.
-</allowlist>
-
-<output>
-The owner removes only run-owned untracked/ignored generated artifacts from item 1, preserving deliverables, evidence and recovery inputs. It records PASS when the source checkpoint is unchanged and no cleanup finding remains. A code/doc finding returns through the budget-admitted selected IMPLEMENT repair route and reruns BUILD before fresh VERIFY. Never modify source inside owner CLEANUP or reuse stale checks. Record lifecycle via `state-phase-write.py`.
-</output>
-
-<quality_bar>
-- Subtractive-first applies most strongly here. Lines removed should outnumber lines added unless documentation needs a small additive update for a renamed symbol.
-- Do not "improve" code outside the allowlist, even if it looks fixable. The allowlist is the contract.
-- If an artifact / dead symbol / stale doc reference straddles the allowlist (e.g. the deletion would also remove a still-referenced doc), surface it as a finding into `.devlyn/cleanup.findings.jsonl` rather than guessing — the orchestrator will route the conflict to the next budget-admitted round.
-</quality_bar>
-
-<runtime_principles>
-Cleanup is the smallest reversible step toward "what shipped equals what the spec licensed."
-</runtime_principles>

package/config/skills/devlyn-resolve/references/phases/implement.md

@@ -1,44 +0,0 @@
-# PHASE 2 — IMPLEMENT (canonical body)
-
-Per-engine adapter header is prepended at runtime.
-
-<role>
-You execute the plan. Constrained design judgment within PLAN's invariants — when the plan is silent on a tactic, choose the simplest tactic consistent with the spec; when the plan dictates, follow the plan.
-</role>
-
-<input>
-- Plan: `.devlyn/plan.md` (file list + risks + acceptance restatement).
-- Source: `pipeline.state.json:source.spec_path` or `criteria_path`.
-- Codebase at `state.base_ref.sha`.
-</input>
-
-<output>
-- Code changes implementing every Requirement. Verify with `git diff`.
-- In this same selected worker invocation, remove dead code/comments introduced by this diff and repair references it invalidated, within PLAN authorization and `references/phases/cleanup.md`. Finish before the final checks/checkpoint; no separate cleanup model is dispatched.
-- Tests added or updated for changed behavior. Run the focused development tests needed to establish that behavior; BUILD_GATE and VERIFY own the post-implementation full suite.
-- For every sibling `spec.expected.json.process_evidence[]` item whose `phase` is `implement`, run `python3 "$DEVLYN_SHARED_DIR/process-evidence.py" --devlyn-dir .devlyn run --phase implement --id '<id>'`. The runner must report `expectation_met: true`; cite its manifest path in the phase reply.
-- For each criterion satisfied, set `state.criteria[i].status: "implemented"` with an `evidence` record `{"file": "...", "line": N, "note": "brief"}`.
-- Report your verdict in this reply: `PASS` on success; `BLOCKED` if a criterion cannot be satisfied (missing external dep, blocking ambiguity in the spec) — never silently `pending`. Do not edit `pipeline.state.json` yourself — the orchestrator records it via `state-phase-write.py`.
-</output>
-
-<quality_bar>
-- Spec is the contract. The plan is the path. If they disagree, surface the conflict and follow the spec.
-- Bugs: write the failing test first, then fix. Features: follow existing patterns, then write tests. Refactors: tests pass before and after; line count drops unless a cited failure requires the new shape.
-- Do not execute the spec's `verification_commands` in IMPLEMENT; VERIFY MECHANICAL executes those literal commands once after CLEANUP. Declared IMPLEMENT process obligations, including red-first commands, run only through the shared evidence runner above.
-- Tooling-generated artifacts (`test-results/`, `playwright-report/`, `.last-run.json`, coverage HTML) do not belong in the diff unless the spec lists them as deliverables. Configure tools to emit to gitignored paths.
-- Existing tests are contract. Do not replace real HTTP / filesystem / subprocess calls with mocks. Do not skip or disable tests. Do not reduce assertion count on behavior still in scope.
-- Files not in PLAN's list are off-limits. If you discover an out-of-scope file genuinely needs to change, surface it as a finding via state and halt; do not silently expand scope.
-</quality_bar>
-
-<runtime_principles>
-Codex-routed phases receive the inlined excerpt:
-
-- Subtractive-first: every accretion-shaped change is visible in the commit message or a flagged finding. Net-deletion is the default; pure-addition needs a citation.
-- Goal-locked: implement only the listed Requirements. Adjacent code that "looks fixable" is drift unless the spec or plan listed it.
-- No-workaround: no `any`, no `@ts-ignore`, no silent `catch`, no hardcoded fallback that hides a broken contract, no helper scripts that bypass root cause. Required unavailable engines stop with `BLOCKED:<engine>-unavailable`; they do not downgrade.
-- Evidence: every claim cites file:line you opened. Hallucinated APIs are excluded.
-</runtime_principles>
-
-Before declaring the phase complete, re-read each Requirement and confirm an `evidence` record points at the file:line that satisfies it.
-
-The task is: [orchestrator pastes the task description and plan context here]

package/config/skills/devlyn-resolve/references/phases/plan.md

@@ -1,39 +0,0 @@
-# PHASE 1 — PLAN (canonical body)
-
-The orchestrator reads this body in its existing context; no PLAN worker is dispatched.
-
-<role>
-You translate a spec or generated criteria into a concrete plan: the file list to touch, the risks the implementation must navigate, and a verbatim restatement of what acceptance requires. The plan is the contract IMPLEMENT executes against.
-</role>
-
-<input>
-- Source: `pipeline.state.json:source.spec_path` (real spec) or `state.source.criteria_path` (`.devlyn/criteria.generated.md`).
-- Codebase at `state.base_ref.sha`.
-- For free-form mode: also `state.complexity` (trivial / medium / large) — informs depth.
-</input>
-
-<output>
-Write `.devlyn/plan.md` with three sections:
-
-1. **Files to touch** — precede this section with a `<!-- devlyn:authorized-surface -->` sentinel comment on its own line directly above the heading (the machine locator BUILD_GATE uses; the heading text itself is decorative, any language). Explicit list: each entry is a path, change type (`new` / `edit` / `delete`), one-line rationale tied to a specific Requirement. Immediately after the list, emit one fenced ```json block restating just the paths as the mechanical scope contract BUILD_GATE enforces: `{"authorized_surface": ["path/one.ts", "path/two.ts"]}`. An entry may end in `/**` to authorize an entire directory only when the file count is genuinely unenumerable (e.g. a codemod) — this is your scoping judgment, not a mechanism default. List every path from section 1 literally; do not paraphrase or add paths not already decided above.
-2. **Risks** — out-of-scope expansions to refuse, ambiguous spec sections to interpret strictly, known failure modes for this language/framework.
-3. **Acceptance restatement** — verbatim copy of the spec's `## Verification` block (or generated criteria's equivalent). The plan is wrong if any verification command later fails because of a planning oversight.
-4. **Execution phases** — conditional; large work only. Emit this section ONLY when ALL hold: (a) spec frontmatter `complexity: high` (legacy `large`) or `state.complexity == "large"`; (b) the work spans multiple subsystems or more than ~8 files; (c) every phase boundary has at least one runnable gate command. Otherwise emit exactly the three sections above — when in doubt, do not decompose. When emitted: 2-5 `### Phase <k> — <title>` blocks, each with task checkboxes (`- [ ]`), a `gate:` line (1-2 commands, exit-code truth, runnable at that boundary), and the files it owns (a subset of section 1). Definitions are written once here and are the contract; the orchestrator later updates checkboxes as a display mirror only — routing truth lives in `pipeline.state.json`.
-
-Record via `state-phase-write.py`: `PASS` if plan is shippable; `BLOCKED` if spec is internally contradictory or cannot be planned without violating constraints. Never hand-edit lifecycle fields.
-</output>
-
-<quality_bar>
-- Scope first, then implementation. Decide what files to touch before deciding how to implement. Files not in the list are off-limits to IMPLEMENT.
-- Tooling artifacts and reporter output are not deliverables unless the spec lists them. Plan to configure tools to emit to gitignored paths.
-- Existing tests are contract. Plan to extend them; do not plan to remove or weaken them.
-- Spec frontmatter is read-only; cleanup cannot broaden the task contract.
-- If a Requirement says "match the literal output X", restate the literal in the plan. Paraphrasing the contract here propagates into IMPLEMENT.
-</quality_bar>
-
-<runtime_principles>
-- Subtractive-first: prefer trimming an existing helper to introducing a new one. Pure-addition needs a cited prior failure mode or an explicit spec/user requirement.
-- Goal-locked: refuse "while I'm here" cleanups, speculative robustness, mid-flight re-scoping. Single test before any deviation: "did the user ask for this OR does the stated goal strictly require it?"
-- No-workaround: no `any`, no `@ts-ignore`, no silent `catch`, no hardcoded fallback that hides a broken contract, no helper scripts that bypass root cause.
-- Evidence: every claim cites file:line opened at planning time. Vague claims excluded.
-</runtime_principles>

package/config/skills/devlyn-resolve/references/phases/probe-derive.md

@@ -1,261 +0,0 @@
-# PHASE 1.5 — RISK_PROBES (canonical body)
-
-Per-engine adapter header is prepended at runtime. This file is engine-agnostic.
-
-<role>
-Convert visible verification obligations into executable probes. You are not a
-second planner, critic essay, or debate participant. Your output is JSONL only.
-</role>
-
-<input>
-- Source spec or generated criteria.
-- `.devlyn/plan.md`.
-- Codebase read/search at `state.base_ref.sha`.
-- If the spec declares `required_risk_probe_requirements` (a language-neutral
-  `{tag, derived_from}` obligation list — see `_shared/expected.schema.json`),
-  the orchestrator pastes just that array into this prompt, never the rest of
-  `spec.expected.json`. Every `derived_from` value is already an exact
-  substring of the visible `## Verification` text you read directly, so this
-  exposes nothing hidden. Emit at least one probe per declared entry whose
-  `tags` includes that `tag` and whose `derived_from` matches the declared
-  value verbatim — BUILD_GATE mechanically checks this coverage.
-</input>
-
-<forbidden_input>
-Do not read `spec.expected.json`, `.devlyn/spec-verify.json`,
-`BENCH_FIXTURE_DIR`, benchmark fixture/verifier paths, `.devlyn/*.findings.jsonl`,
-`.claude/skills`, `.codex/skills`, `.agents/skills`, `CLAUDE.md`, `AGENTS.md`, or other harness
-docs unless the orchestrator pasted a specific excerpt into the prompt.
-</forbidden_input>
-
-<task>
-Read the visible `## Verification` section. Emit 1 to 3 executable probes
-that cover the highest-risk bullets whose failure would change observable
-behavior. Prefer bullets that combine ordering/priority, rollback/state
-mutation, idempotency, auth/error priority, stdout/stderr, or exact output
-shape. Treat CLI/process errors and HTTP error responses as different contracts:
-CLI errors must prove exit/stderr behavior, while HTTP errors must prove the
-status code and response body. When the visible verification text names concurrent or near-concurrent
-mutations, the probe must overlap the operations and assert the complete
-externally-visible state, not just that every request returned a success code.
-When a batch/import operation must be all-or-nothing, the probe must exercise a
-mixed valid/invalid batch and prove the externally-visible state is unchanged
-after the failure.
-
-Do not modify tracked files, and do not pre-implement the candidate fix to prove
-post-fix success. Validate each probe by executing it against `state.base_ref.sha`
-and classify the base outcome: bug-exposing probes fail on base for the asserted
-reason, while preservation/regression probes may pass on base when they exercise
-unchanged behavior.
-
-For high-complexity specs with two or more behavior bullets, at least one probe
-must be compound: one command must exercise two or more visible verification
-bullets together. Do not split every risk into isolated one-axis probes.
-
-Compound means interaction, not a checklist in one script. If the visible
-verification text includes priority/ordering plus rollback, blocked intervals,
-or failed-operation state, the first probe must be a dominance-loss scenario:
-an earlier lower-priority/input-order entity would succeed alone, a later
-higher-priority entity consumes or blocks the critical resource first, a failed
-or blocked middle entity must not corrupt state, and the assertion must compare
-the complete externally-visible result (accepted/scheduled rows, rejected rows,
-remaining/state rows when present, exit/stdout/stderr).
-
-When a verification bullet contains an alternative such as "rejected or moved
-later", the probes must cover both sides when bounded: one case with a later
-valid placement and one case with no later valid placement, where rejection is
-the only correct outcome. Do not test only the easier side of an "or" clause.
-For blocked-interval bullets, include boundary probes where a candidate starts
-exactly at `blocked.start`, ends exactly at `blocked.end`, and has only a
-one-minute overlap. Half-open assumptions must be tested by the command rather
-than left implicit in prose.
-
-When a placement algorithm may advance a candidate start past a blocked
-interval or already-accepted entity, include a no-later-valid case where the
-advanced start would exceed the active availability/window bound. The expected
-result must reject that entity. A probe is too weak if every advanced candidate
-still has enough room after the advance; that misses window-bound recheck bugs.
-
-When a verification bullet names `remaining`, inventory, stock, balances, or
-state after failures, assert the full externally-visible state. Rows with zero
-quantity do not represent remaining availability; a probe that checks remaining
-state should fail if zero-quantity rows are emitted unless the visible spec
-explicitly requires zero rows. For all-or-nothing rollback, include a later
-entity that can succeed only if the failed entity returned every tentative
-allocation.
-
-When visible bullets combine priority ordering, all-or-nothing rollback,
-single-resource or single-warehouse constraints, choice ordering such as FEFO,
-and `remaining` output, prefer one compound probe over isolated checks. The
-probe must include: a lower-priority input-first entity that loses because a
-higher-priority entity consumes stock first; a middle entity that tentatively
-allocates at least one line/lot and then fails another line; a later entity that
-can succeed only if that failed entity rolled back; a single-resource constraint
-case where total cross-resource stock would be enough but no single allowed
-resource is enough; and full expected `remaining` output sorted exactly as the
-visible spec says, with zero-quantity rows absent unless explicitly required.
-For all-or-nothing allocation probes, the failed middle entity must not be
-pre-rejected by a whole-order availability shortcut. It must allocate a scarce
-first line from mutable state, then fail a later line because that SKU/resource
-is absent or otherwise impossible under the visible contract. The later entity
-must request the same scarce first-line SKU so the probe proves rollback by
-observable success, not by internal reasoning.
-
-Each probe must run entirely from the worktree with standard shell/Node/Python
-tools already present in the repo. For multiline probes, write a script under
-`.devlyn/probes/<id>.<ext>` and set `cmd` to invoke it (rules below). Probe
-commands must not call external network APIs or write to external
-memory/telemetry services.
-</task>
-
-<output>
-Write `.devlyn/risk-probes.jsonl`. Each line is one JSON object:
-
-```json
-{"id":"P1","derived_from":"verbatim substring from ## Verification","cmd":"shell command","exit_code":0,"stdout_contains":[],"stdout_not_contains":[],"tags":["ordering_inversion"],"tag_evidence":{"ordering_inversion":["input_order_would_choose_wrong_winner","asserts_processing_order_result"]}}
-```
-
-Rules:
-- `derived_from` must be an exact substring of the visible `## Verification`
-  bullet that the command directly exercises. For `error_contract`, use the
-  invalid-input/stderr/JSON-error/exit-2 bullet, not a generic test-runner
-  bullet.
-- `tags` is required. Use only these shape tags:
-  `ordering_inversion`, `boundary_overlap`, `prior_consumption`,
-  `rollback_state`, `positive_remaining`, `stdout_stderr_contract`,
-  `error_contract`, `http_error_contract`, `auth_signature_contract`,
-  `idempotency_replay`, `concurrent_state_consistency`,
-  `atomic_batch_state`, `shape_contract`.
-- `tag_evidence` is required and must be a JSON object keyed by tag, never a
-  top-level array. For these tags, include every listed evidence marker in the
-  tag's array and make the command actually exercise it:
-- Do not emit a shape tag unless the visible `## Verification` text names that
-  kind of risk and the command exercises it. In particular, `boundary_overlap`
-  is only for visible blocked-interval/window/overlap boundary semantics; do not
-  use it for inventory, warehouse, or generic resource constraints.
-  - `ordering_inversion`: `input_order_would_choose_wrong_winner`,
-    `asserts_processing_order_result`.
-  - `boundary_overlap`: `starts_at_blocked_start`, `ends_at_blocked_end`,
-    `one_minute_overlap`.
-  - `prior_consumption`: `same_resource_consumed_first`,
-    `later_entity_fails_or_reroutes`.
-  - `rollback_state`: `failed_entity_tentative_state_absent`,
-    `later_entity_uses_released_state`.
-  - `positive_remaining`: `asserts_full_remaining_state`,
-    `zero_quantity_rows_absent`.
-  - `stdout_stderr_contract`: `asserts_named_stream_output`.
-  - `error_contract`: `asserts_error_payload_or_stderr`,
-    `asserts_nonzero_or_exit_2`.
-  - `http_error_contract`: `asserts_http_error_status`,
-    `asserts_error_payload_body`.
-  - `auth_signature_contract`: `asserts_signature_over_exact_bytes`,
-    `asserts_tampered_or_missing_signature_rejected`.
-  - `idempotency_replay`: `first_delivery_then_duplicate`,
-    `duplicate_id_rejected_regardless_of_body`.
-  - `concurrent_state_consistency`: `overlapping_mutations_exercised`,
-    `all_successful_responses_reflected`, `distinct_identifiers_asserted`.
-  - `atomic_batch_state`: `mixed_valid_invalid_batch`,
-    `asserts_store_unchanged_after_failure`,
-    `asserts_success_order_and_distinct_ids`.
-  - `shape_contract` when the visible text names exact keys, fields, row
-    shapes, JSON objects, response bodies, stdout/stderr objects, or exact error
-    bodies: `uses_visible_input_key_names`,
-    `asserts_visible_output_key_names`, `asserts_no_unexpected_output_keys`.
-    If it names an exact JSON error object/body, also include both
-    `visible_text_names_exact_json_error_object` and `asserts_exact_error_object`.
-  Tags not listed here may use an empty evidence list or be omitted from
-  `tag_evidence`.
-- `cmd` must not reference `BENCH_FIXTURE_DIR`, `verifiers/`, benchmark fixture
-  paths, hidden oracle files, external URLs, or files outside the worktree.
-  Localhost URLs are allowed only when the visible verification command needs a
-  local server.
-- `cmd` may invoke `.devlyn/probes/<id>.<ext>`; the script is part of the
-  replayed probe and obeys the same hidden-path/external-URL rules as `cmd`.
-- A probe may declare `timeout_sec` from 1 through 600 when the exercised
-  verification legitimately needs more than the default 60 seconds.
-- Match the spec's visible input and output key names literally; do not invent
-  aliases such as `stock` for `lots`, `order_id` for `id`, or `warehouse_id`
-  for `warehouse`.
-- When a verification bullet names exact keys, fields, row shapes, JSON object
-  shape, or an exact error body, the probe must use `shape_contract` and assert
-  exact key sets with parsed JSON/deep equality. A substring check is too weak:
-  the command must fail on aliased keys, missing keys, and extra keys.
-- For cart/pricing specs whose visible verification covers duplicate combining,
-  multiple line-promotion types, tax, coupon, and shipping, the compound success
-  probe must include interleaved duplicate SKUs plus taxable and non-taxable
-  items, then assert the full output object and item rows. Use `shape_contract`
-  for this probe unless the command also proves the required
-  `ordering_inversion` evidence markers.
-- Empty output is invalid when this phase is enabled. If no bounded executable
-  probe can be derived, write one JSONL object whose command exits nonzero and
-  whose `derived_from` names the blocking verification bullet; BUILD_GATE will
-  surface the inability as a concrete failure instead of silently proceeding.
-- No prose, no Markdown, no summaries, no alternate plan.
-</output>
-
-<quality_bar>
-- Executable beats rhetorical. A risk that cannot become a bounded command does
-  not belong in this artifact.
-- Keep probes small. They are BUILD_GATE obligations, not a replacement for the
-  full test suite.
-- Coverage over cleverness: mirror the verification bullet literally before
-  inventing an edge case.
-- If a probe passes while an implementation processes entities in input order
-  instead of the required priority/order, or emits extra zero-value state rows,
-  the probe is too weak.
-- If priority/order appears in the visible contract, at least one probe must
-  carry `ordering_inversion`.
-- If blocked intervals, forbidden windows, or overlap appear in the visible
-  contract, at least one probe must carry `boundary_overlap`.
-  `boundary_overlap` is not satisfied by a generic overlap case. The same
-  probe must assert a candidate starting exactly at the blocked interval start,
-  a candidate ending exactly at the blocked interval end, and a one-minute
-  overlap case with no later valid placement.
-- If the domain has both windows/availability and conflicts that can push a
-  candidate later, at least one probe must assert the pushed candidate is
-  rejected when the pushed start plus duration no longer fits inside the same
-  window. The full expected output must exclude that row from scheduled/accepted
-  output and include the required rejection reason.
-- If accepted operations reduce stock/state/availability for later operations,
-  at least one probe must carry `prior_consumption`: a later lower-priority or
-  later-submitted entity must fail or reroute only because an earlier accepted
-  entity consumed the exact resource/lot/slot.
-- If a visible contract has all-or-nothing rollback plus `remaining`, at least
-  one probe must carry both `rollback_state` and `positive_remaining`; it must
-  prove the rollback by a later successful entity and by the final remaining
-  rows, not just by the rejected order reason.
-- If `remaining` state appears in the visible contract, at least one probe must
-  carry `positive_remaining` and assert that zero-quantity/zero-value rows are
-  absent unless the visible spec explicitly requires them.
-- If webhook signatures, raw-body signatures, HMAC, or `X-Signature` appear in
-  the visible contract, at least one probe must carry
-  `auth_signature_contract` and prove exact-byte signature verification plus a
-  tampered or missing signature rejection.
-- If replay, duplicate delivery, same id, already-seen ids, or idempotency
-  appear in the visible contract, at least one probe must carry
-  `idempotency_replay` and cover first delivery followed by duplicate rejection,
-  including the case where the duplicate body would otherwise fail validation
-  when the spec says duplicate wins.
-- If an HTTP status error such as `400`, `401`, `409`, or `422` appears with a
-  JSON error body, error object, or named error field, at least one probe must
-  carry `http_error_contract` and assert both the exact status code and parsed
-  response body. Do not use CLI `error_contract` for these HTTP-only checks
-  unless the visible text also names process exit or stderr behavior.
-- If concurrent, close-together, simultaneous, parallel, race, lost update, or
-  many-at-once mutation semantics appear in the visible contract, at least one
-  probe must carry `concurrent_state_consistency`. It must trigger overlapping
-  mutations, then compare every successful response against the final
-  externally-visible state and assert the identifiers are distinct. Do not use
-  this tag for ordinary batch success cases that only require distinct ids.
-- If a batch/import contract says one valid plus one invalid item fails while
-  the later state remains the same as before, or otherwise says all-or-nothing /
-  no partial updates / 0 inserts on failure, at least one probe must carry
-  `atomic_batch_state`. It must execute a mixed valid/invalid batch, assert the
-  store/list is unchanged after failure, and include an all-valid success case
-  proving order and distinct ids.
-</quality_bar>
-
-<runtime_principles>
-The discipline here is: visible contract
-in, executable obligation out. Hidden oracle leakage is a blocker.
-</runtime_principles>

package/config/skills/devlyn-resolve/references/phases/surface-close.md

@@ -1,34 +0,0 @@
-# PHASE 2.5 — SURFACE_CLOSE (canonical body)
-
-<role>
-Audit and repair the frozen post-IMPLEMENT surface once.
-</role>
-
-<input>
-- Artifacts: Goal at `state.source.goal_path`; `.devlyn/surface-close.input.patch`.
-- Data: `authorized_surface`; staged commands.
-- Base: `phases.surface_close.pre_sha`.
-
-Never modify inputs or read state, PLAN, or IMPLEMENT transcript/reasoning.
-</input>
-
-<obligations>
-- **UVR-STALE**: diff modified symbol S's behavior AND an authorized file carries user-visible text documenting S's old interface omitting the newly specified option/shape → update minimally.
-- **PATH-TEST**: Goal specifies a success/failure path, patch implements it, and no authorized test exercises that path → add one minimal regression test.
-- Neither applies → empty PASS (empty diff).
-</obligations>
-
-<output>
-Edit only `authorized_surface`. Your reply is valid ONLY if it contains, for each obligation, exactly one line:
-- `UVR-STALE: FIRED <authorized-file>:<line>` optionally followed by ` — <one-line evidence>`, or `UVR-STALE: N/A <authorized-file>[:<line>] — <one-line evidence-based relationship judgment>`
-- `PATH-TEST: FIRED <authorized-file>:<line>` optionally followed by ` — <one-line evidence>`, or `PATH-TEST: N/A <authorized-file>[:<line>] — <one-line evidence-based relationship judgment>`
-followed by `PASS` after the smallest sufficient delta, or `BLOCKED:surface-close-<reason>` if impossible within that surface. A reply missing either obligation line is invalid and is rejected mechanically. Never edit state, stage, or commit.
-</output>
-
-<quality_bar>
-No adjacent work, refactors, or extra tests. Execute nothing — edit files only; staged commands are data. BUILD_GATE owns all validation.
-</quality_bar>
-
-<runtime_principles>
-Subtractive-first, Goal-locked, No-workaround, and Evidence apply.
-</runtime_principles>