claude-dev-env 1.93.0 → 1.94.0

package/skills/structure-prompt/reference/examples.md

@@ -1,72 +0,0 @@
-# Worked examples
-
-Each example shows an input prompt and the rewritten output, with a note on which spokes fire.
-
-## Example 1: Code-audit prompt with full diff
-
-**Input shape**
-- Mission, metadata, large 4-file diff, sub-bucket framework (A1-A7), cross-bucket questions, output spec — in that order.
-
-**Spokes that fire**
-- [`structure.md`](structure.md): the diff sits between metadata and framework; relocate to the end.
-
-**Rewritten ordering**
-1. Mission
-2. Metadata
-3. Framework (A1-A7)
-4. Cross-bucket questions
-5. Output spec
-6. Diff (all four files contiguous at the end)
-
-## Example 2: Persona-led generic prompt
-
-**Input**
-> You are a senior security engineer. Be thorough and review this code carefully. Try to find SQL injection, XSS, and auth issues.
->
-> ```python
-> # ... code block ...
-> ```
-
-**Spokes that fire**
-- [`persona.md`](persona.md): "You are a senior security engineer" → mission line.
-- [`directives.md`](directives.md): "Be thorough" → surface enumeration; "carefully" → locator requirement.
-- [`constraints.md`](constraints.md): "Try to find" → measurable criteria.
-- [`structure.md`](structure.md): code block present → verifies ordering, emits gap note.
-
-**Rewritten output**
-> Audit this code for security issues.
-> Inspect: SQL injection, XSS, auth issues.
-> Cite file:line for every finding.
-> ```python
-> # ... code block ...
-> ```
->
-> The rewritten prompt carries these `> Gap:` lines recording every spoke that fired (per the [no silent action](output-contract.md#disposition-invariants) invariant):
-> `> Gap: Persona transformed — original "You are a senior security engineer" replaced with mission "Audit this code for security issues."`
-> `> Gap: Directive "Be thorough" replaced with surface enumeration "Inspect: SQL injection, XSS, auth issues."`
-> `> Gap: Directive "carefully" replaced with locator requirement "Cite file:line for every finding."`
-> `> Gap: Narrative directive "Try to find" merged with directives output — both derived the same measurable criteria "Inspect: SQL injection, XSS, auth issues."`
-> `> Gap: Structural ordering verified — input already in canonical sequence.`
-
-## Example 3: Multi-category framework without disposition
-
-**Input shape**
-- Framework names 5 categories. No per-category requirement on emission.
-
-**Spokes that fire**
-- [`per-category.md`](per-category.md): insert canonical disposition line under the category list header.
-
-**Inserted line**
-> Each category returns either at least one finding with a locator OR exactly one proof-of-absence with at least 3 adversarial probes specific to that category. A category returning neither is a protocol gap.
-
-## Example 4: Already-optimized prompt
-
-**Input**
-- Mission first, framework before data body, persona absent, multi-category disposition present, no soft directives, code block tagged.
-
-**Spokes that fire**
-- [`structure.md`](structure.md): code block present → verifies ordering, emits `> Gap:` note recording the check.
-- [`per-category.md`](per-category.md): multi-category framework present → confirms disposition line exists, emits `> Gap:` note.
-
-**Rewritten output**
-- Identical to input save for the appended gap notes from structure and per-category.

package/skills/structure-prompt/reference/instantiation.md

@@ -1,51 +0,0 @@
-# Fill placeholders with real values
-
-Some prompts ship as templates with placeholder tokens. The skill replaces those with concrete values pulled from the rubric, the companion artifact, or the user.
-
-## Detection patterns
-
-A placeholder is any bracketed token whose content reads as instructional rather than a literal name. Common shapes:
-
-- `[REPO/ARTIFACT]`
-- `[TARGET ID]`
-- `[N]`
-- `[ARTIFACT METADATA]`
-- `[INLINE THE FULL ARTIFACT HERE — do not ask the agent to fetch.]`
-- `[List the supported …]`
-- `[Declared minimum …]`
-- `[file:line / paragraph]`
-- `[A1]–[AN]`, `[B1]–[BN]`, etc.
-
-## Procedure
-
-1. Find every placeholder in the prompt.
-2. For each placeholder, look up the value via [`research.md`](research.md).
-3. Replace the placeholder with the real value.
-4. For placeholders matching `[INLINE THE FULL ARTIFACT HERE …]` (any placeholder that opens with `INLINE THE FULL ARTIFACT`, including the long-form `[INLINE THE FULL ARTIFACT HERE — do not ask the agent to fetch.]`), the artifact's text comes from one of the sources [`research.md`](research.md) enumerates — a local file the user named when invoking in file-path mode, a sibling artifact the rubric points at, content the user pasted alongside the prompt, or a path the user supplied via AskUserQuestion. Inline that text as fenced code blocks, using each file's path as a `###` heading above its fenced block. The skill never reaches outside those sources for retrieval; when none of them yields the artifact, the spoke leaves the placeholder in place and records a gap per [`output-contract.md`](output-contract.md).
-
-## When the rubric points at a sibling prompt
-
-Rubric files often say "use category-X.md as the canonical worked example." When that happens:
-
-1. Read the sibling prompt.
-2. Copy the sibling's data body — the inlined artifact — into this prompt's data body.
-3. Sharpen this prompt's sub-bucket bullets so they cite the identifiers in the data body that match this category's axes.
-4. Keep the category-specific phrasing intact. Only the data body and the per-bucket bullets that reference data-body content change.
-
-## Sub-buckets that have nothing to find in the data body
-
-When the data body holds nothing that fits a particular sub-bucket (e.g., a SQL sub-bucket and a diff with no SQL), that sub-bucket stays as a proof-of-absence shape. Spell out three adversarial probes the agent runs to confirm zero relevant content. Use the sub-bucket bullets to name the things the agent searches for.
-
-## What stays put
-
-These elements pass through untouched:
-
-- The mission's category name (e.g., "Category B only") — derived from the file name, not the artifact
-- The per-category disposition statement
-- The cross-bucket question structure (Q1, Q2, Q3 by name)
-- The output spec's lead format (`Total: N (P0=N, P1=N, P2=N)`)
-- The adversarial-pass count and severity tier — handled by [`adversarial-tuning.md`](adversarial-tuning.md) when the noun needs sharpening; the count and tier values come from the original prompt's own adversarial phrase, not a fixed default
-
-## Disposition reporting
-
-Every outcome emits an action note via the mechanism that [`output-contract.md`](output-contract.md) defines. When placeholders were filled: `> Gap: Placeholders instantiated — <N> placeholders replaced with real values.` When no placeholders exist: `> Gap: Instantiation verified — no placeholder tokens found.` When a placeholder could not be resolved: `> Gap: Placeholder "<token>" left in place — no real value found in available sources.` Silent pass is forbidden — see the [no silent action](output-contract.md#disposition-invariants) invariant.

package/skills/structure-prompt/reference/output-contract.md

@@ -1,72 +0,0 @@
-# Output contract
-
-The skill emits exactly one artifact: the rewritten prompt. The emission shape depends on how the input arrived.
-
-## Emission modes
-
-**Paste mode** — input arrives as the user's message body or as a fenced block within it. Emit one fenced block containing the rewritten prompt. Choose a fence length that is strictly longer than the longest consecutive backtick run anywhere in the rewritten prompt (i.e., `max_backtick_run + 1`, with a minimum of four backticks). This ensures no inner fence in the rewritten prompt can prematurely close the outer fence — including cases where the input already used a 4+ backtick wrapper:
-
-``````
-`````
-<rewritten prompt, which may itself contain 4-backtick fences>
-`````
-``````
-
-**File-path mode** — input arrives as a file path argument (e.g., `/structure-prompt path/to/file.md`). File-path mode targets Markdown prompt artifacts; rewriting non-Markdown files is not supported. Rewrite the file in place. Emit a confirmation that names the file, gives the line-count delta, and lists the spokes that fired. When gaps exist, the confirmation also lists them — the output may span multiple lines.
-
-## Disposition invariants
-
-**No silent action** (also referenced as "no silent no-op"). Every spoke that fires MUST record its action. Two cases use the same `> Gap:` mechanism:
-
-- **Deferred.** The spoke elected not to apply its transformation — missing source, ambiguous detection, fallback to user input, carve-out match, or any other reason. The gap note records what was deferred and why.
-- **Applied.** The spoke successfully applied its transformation. The gap note records what changed (e.g., persona transformed, directive replaced, citation added) so the reader can detect the change.
-
-Silent omission is never the correct disposition in either case. The reader of the output must always be able to detect which spokes fired, which deferred, and why.
-
-## Preservation invariants
-
-Two clauses govern what the rewritten prompt may change.
-
-**Existing input content is preserved byte-for-byte.** The rewrite must not alter any of these values when they already appear in the input:
-
-- Identifiers (variable names, function names, file paths)
-- IDs and SHAs
-- ID prefixes
-- Proper names (people, products, services)
-- Numeric values (line numbers, thresholds, counts)
-- URLs
-- Code block contents
-
-**New numeric criteria are additive content.** When a spoke introduces a new measurable threshold (e.g., the `≥3` adversarial probes from [`per-category.md`](per-category.md), the citation-occurrence cutoffs from [`citation-depth.md`](citation-depth.md), or any new word/probe/count limit), that number is sourced per the authorized-additions list below. New numeric criteria augment the prompt; they never overwrite a numeric value the input already carries.
-
-## Idempotency
-
-Output stabilizes by the second invocation: the second and all subsequent invocations produce identical output (i.e., `f(f(x)) == f(f(f(x)))`). On the first invocation, content-mutating spokes (persona, cleanup, directives, constraints, adversarial-tuning, instantiation, citation-depth, canonical-case) apply their transformations and emit "applied" gap notes alongside situation-dependent spokes (structure, per-category) that re-fire because their input conditions still hold. On the second invocation, those mutating spokes no longer match their detection conditions (placeholders substituted, identifiers cited, markers present, noun sharpened, canonical sub-bucket marked), so their gap notes disappear and situation-dependent notes shift to "verified" wording. Combined with the gap-report block's deterministic replacement, the second invocation's output is stable: a third invocation produces identical output.
-
-## Authorized additions
-
-The skill adds content only when a spoke explicitly authorizes it. Evidence-required additions (cited values from the rubric, placeholder values from the input or user) must also pass [`research.md`](research.md) confirmation that the new content matches a real source (rubric, sibling artifact, user-pasted context, or AskUserQuestion answer). Skill-defined additions (the per-category disposition line, surface-formatting cleanup, the failure-mode noun from the adversarial-tuning built-in lookup table) are authorized by their spoke firing alone. The authorized additions are:
-
-- The mission line, when [`persona.md`](persona.md) replaces a role assignment
-- The per-category disposition line, when [`per-category.md`](per-category.md) detects an unenforced framework
-- Measurable criteria, when [`directives.md`](directives.md) or [`constraints.md`](constraints.md) replaces a soft directive
-- Real values in place of placeholders, when [`instantiation.md`](instantiation.md) fires
-- `file:line` citations on identifier mentions, when [`citation-depth.md`](citation-depth.md) fires
-- The ⭐ canonical-case marker on one sub-bucket, when [`canonical-case.md`](canonical-case.md) fires
-- A category-specific failure-mode noun in the adversarial-pass phrase, when [`adversarial-tuning.md`](adversarial-tuning.md) fires
-- Surface-formatting normalization (typo correction, single bullet style, language tags on fenced blocks, trimmed trailing whitespace, collapsed blank-line runs, sequential heading levels), when [`cleanup.md`](cleanup.md) fires
-- `(citation unavailable: <reason>)` inline markers adjacent to unciteable identifiers, when [`citation-depth.md`](citation-depth.md) fires
-
-Skill-defined additions (the per-category disposition line, surface-formatting cleanup, the failure-mode noun from [`adversarial-tuning.md`](adversarial-tuning.md)'s built-in lookup table) are authorized by their spoke firing alone — they do not need an external source. For evidence-required additions (cited values from the rubric, placeholder values from the input or user), [`research.md`](research.md) confirms the new content matches a real source. When evidence is missing for an evidence-required addition, the spoke leaves the prompt as-is and reports the gap. For a skill-defined addition, once the spoke's detection conditions are met the transformation fires and always emits an action note recording what changed — the spoke does not need external evidence beyond its own rubric, unlike evidence-required additions. (Skill-defined additions are still situation-dependent per the routing table; "fires" here means when the spoke is active, not on every invocation.) The "No silent action" invariant applies to both applied and deferred outcomes. The gap-report shape depends on emission mode:
-
-- **Paste mode.** The fenced block contains exactly the rewritten prompt — no footer follows it. Record gaps inside the fenced block as a final blockquoted note prefixed `> Gap:` (one line per gap). The note sits below the rewritten prompt's last block and remains inside the fence. On a second invocation, prior-run `> Gap:` lines are deterministically replaced (not accumulated): the current run's gap notes overwrite any prior-run gap notes, ensuring idempotent output across invocations. The passthrough rule in [`block-classification.md`](block-classification.md) step 3 still treats the prior-run gap region as inert during block tagging, but the current run's gap line emission replaces rather than appends.
-- **File-path mode.** The rewritten file on disk MUST be self-describing for gaps. Append a final HTML comment block at the bottom of the file. The block opens with `<!-- gap-report:` on its own line, contains one `> Gap:` line per gap, and closes with `-->` on its own line. The `<!-- gap-report:` block is deterministically replaced (never accumulated) to reflect the current run's gap state. When the current run has gaps, a new `<!-- gap-report:` block containing the gap lines overwrites any prior block. When the current run has no gaps, any prior block is replaced with `<!-- gap-report: none -->` — the file always carries a self-describing gap-report block so a reader can determine the latest run's gap state without external context. Example for a run with two gaps:
-
-  ```
-  <!-- gap-report:
-  > Gap: Persona transformed — original "You are an expert code reviewer" replaced with mission "Find bugs in this code."
-  > Gap: canonical-case marker skipped — framework has 5+ sub-buckets but rubric match, bullet density, and identifier density found no clear canonical case
-  -->
-  ```
-
-  The post-edit confirmation message that names the file and the spokes that fired ALSO lists the same gaps, but the file itself is now self-describing — a reader of the file alone can detect which spokes deferred and why.

package/skills/structure-prompt/reference/per-category.md

@@ -1,23 +0,0 @@
-# Per-category disposition
-
-Every multi-category framework requires each category to emit exactly one disposition:
-- At least one positive finding with a locator (file:line, section ID, line number, or equivalent) per category
-- Exactly one explicit proof-of-absence with at least 3 adversarial probes specific to that category
-
-## Detection
-
-The framework names 2+ categories, surfaces, sub-buckets, items, checks, or criteria the agent processes.
-
-## Insertion
-
-Insert this exact line directly under the category list header, substituting `<category-noun>` with whatever the prompt calls them (sub-bucket, surface, item, category, check, criterion):
-
-> Each `<category-noun>` returns either at least one finding with a locator OR exactly one proof-of-absence with at least 3 adversarial probes specific to that `<category-noun>`. A `<category-noun>` returning neither is a protocol gap.
-
-## Idempotency
-
-When the framework already states an equivalent requirement (positive finding OR proof-of-absence with ≥3 probes), leave it intact. Insert only when the requirement is absent or weaker than the canonical form.
-
-## Disposition reporting
-
-Every outcome emits an action note via the mechanism that [`output-contract.md`](output-contract.md) defines. When the disposition line was inserted: `> Gap: Per-category disposition line inserted under category list header.` When the framework already carries the canonical form: `> Gap: Per-category disposition verified — canonical form already present.` Silent omission is forbidden — see the [no silent action](output-contract.md#disposition-invariants) invariant.

package/skills/structure-prompt/reference/persona.md

@@ -1,38 +0,0 @@
-# Persona transformation
-
-Lead the optimized prompt with what the agent does, not who the agent is.
-
-## Detection patterns
-
-The persona block matches any of:
-- "You are a/an `<role>`"
-- "You are an expert in/at `<topic>`"
-- "You are a helpful assistant"
-- "Act as `<role>`"
-- "Pretend to be `<role>`"
-- "Imagine you are `<role>`"
-- "As a/an `<role>`, …"
-- "Role: `<role>`"
-
-## Transformation
-
-Replace the persona line with a single mission sentence stating the task in imperative form.
-
-| Persona input | Mission output |
-|---|---|
-| "You are a senior security engineer. Review this PR." | "Audit this PR for security issues." |
-| "Act as a code reviewer and find bugs in this code." | "Find bugs in this code." |
-| "You are an expert at SQL. Write a query that…" | "Write a SQL query that…" |
-
-## Creative-writing carve-out
-
-The persona line stays intact when the prompt explicitly references one of these output qualities: `style`, `tone`, `voice`, `fiction`, `creative writing`, `narrative`. In that case the persona shapes the output's character and the mission line follows it.
-
-## Disposition reporting
-
-The persona pass MUST emit a gap note via the paste-mode or file-path-mode gap-report mechanism that [`output-contract.md`](output-contract.md) defines, recording one of two dispositions:
-
-- `> Gap: Persona transformed — original "<persona line>" replaced with mission "<mission line>".`
-- `> Gap: Persona preserved (creative-writing carve-out matched: "<matched keyword>").`
-
-When none of the six carve-out keywords appears in the input, the persona line is always transformed. The detection is deterministic: a case-insensitive match against the six listed keywords only. No subjective "near-miss" or "intent" judgment applies. See the [no silent action](output-contract.md#disposition-invariants) invariant.

package/skills/structure-prompt/reference/research.md

@@ -1,33 +0,0 @@
-# When the skill needs information that isn't in the input
-
-Some spokes need information the input prompt doesn't include — like the line number where an identifier lives, the canonical example for a category, or the real value to put where a placeholder sits. This file describes how to find that information from real sources.
-
-## Where to look, in order
-
-1. **The sibling rubric file.** When the calling framework provides a companion rubric (typically at `../category_rubrics/<same-name>.md` in audit-rubric layouts, but the path is framework-specific), read it first. The rubric often spells out the canonical example, the instantiation recipe, and the category-specific failure-mode noun. When no sibling rubric exists for the input prompt, skip this source and proceed to the companion artifact.
-
-2. **The companion artifact.** When the rubric points at a sibling prompt as a worked example (e.g., "see `category-a-api-contracts.md` for the canonical diff"), read that sibling and use its diff or framework as the reference.
-
-3. **The user-supplied context.** When the user pasted an artifact alongside the prompt — a diff, a PR URL, a file dump — use it directly.
-
-4. **AskUserQuestion.** When the three sources above turn up nothing, ask the user via the AskUserQuestion tool. Phrase the question around the specific blocker (e.g., "Which artifact should I instantiate against?") and offer two to four concrete options.
-
-## What counts as evidence
-
-A change earns its place in the rewritten prompt when one of these is true:
-- The rubric file states it
-- The sibling artifact contains it (the line number is real, the identifier sits in the diff)
-- The user-pasted context contains it (the value sits in the prompt body the user supplied, in a fenced block within it, or in an artifact the user pasted alongside the prompt)
-- The user supplied it via an AskUserQuestion answer
-
-When none of the four holds, the spoke leaves the prompt as-is and notes the gap in the location [`output-contract.md`](output-contract.md) defines for the active emission mode. The deferral itself is mandatory — see the [no silent no-op](output-contract.md#disposition-invariants) invariant.
-
-## Tone of the AskUserQuestion
-
-Use everyday phrasing. Tell the user what's blocked and what answers would unblock it.
-
-| What the spoke needs | Question shape |
-|---|---|
-| Which PR or artifact to instantiate against | "I have placeholders in the prompt. Which artifact should I fill them with?" |
-| Which scope of source material to inline | "Should I inline the full diff, the changed files only, or specific paths?" |
-| Which sub-bucket is the canonical case | "The framework has six similarly-weighted sub-buckets. Which one is the canonical case for this category?" |

package/skills/structure-prompt/reference/structure.md

@@ -1,28 +0,0 @@
-# Structural ordering
-
-The optimized prompt presents blocks in this fixed sequence:
-
-1. Mission block
-2. Metadata block
-3. Framework block
-4. Questions block
-5. Output spec block
-6. Data body block
-
-## Procedure
-
-1. Extract each tagged block from the input. The gap-report region (prior-run `> Gap:` lines or `<!-- gap-report:` comment blocks) is excluded from block ordering — it is kept at the end during classification and reordering, then deterministically replaced during emission per [`output-contract.md`](output-contract.md).
-2. Concatenate the blocks in the sequence above.
-3. Preserve every byte of the inputs that [`output-contract.md`](output-contract.md) lists under "Preservation invariants" exactly as supplied.
-
-## Multiple data bodies
-
-When the input contains multiple data body blocks (e.g., several file diffs), group them as a contiguous final section in their original relative order.
-
-## Atomicity
-
-The framework block stays whole. The data body section sits as one contiguous region at the end.
-
-## Disposition reporting
-
-Every outcome emits an action note via the mechanism that [`output-contract.md`](output-contract.md) defines. When blocks were reordered: `> Gap: Blocks reordered to canonical sequence (mission → metadata → framework → questions → output spec → data body).` When the input already follows canonical ordering and no reorder is needed: `> Gap: Structural ordering verified — input already in canonical sequence.` Silent omission is forbidden — see the [no silent action](output-contract.md#disposition-invariants) invariant.

package/skills/verified-build/CLAUDE.md

@@ -1,33 +0,0 @@
-# verified-build
-
-Runs a code task through the two-phase verified workflow: scoped coder agents write the changes, then a fresh-context `code-verifier` agent re-derives and runs every check itself.
-
-**Trigger:** "verified build", "run this verified", "two-phase build", "build and verify", "verified implementation".
-
-## Purpose
-
-Ensures that `git commit`/`git push` open only after a clean, hook-minted verifier verdict bound to the live change surface. The `verified_commit_gate` hook blocks commits and pushes until a verdict covers the current branch diff.
-
-## Key files
-
-| File | Purpose |
-|---|---|
-| `SKILL.md` | The complete skill — workflow checklist, gotchas. No companion files. |
-
-## Workflow (copy-this checklist)
-
-- [ ] Record baselines (test command + exact failure set) before coders start
-- [ ] Scope assignments into file-disjoint tasks with named checks
-- [ ] Spawn one `clean-coder` (or Sonnet) agent per assignment; each consults `code-advisor` on decisions it cannot resolve
-- [ ] Settle the tree after coders finish (run formatters, stage nothing)
-- [ ] Spawn `code-verifier` (fresh context) with task texts, diff scope, and baselines
-- [ ] Repair only reported findings; re-spawn verifier after each repair
-- [ ] Land in one commit + push + draft PR as soon as verdict is clean
-
-## Conventions
-
-- Any file change after the verifier stops re-locks the gate — run formatters before spawning the verifier.
-- The verifier must end with a ` ```verdict ` fence; the `verifier_verdict_minter` hook mints the verdict from that fence.
-- The minter keys on agent type string `code-verifier` — the same prompt under another agent type mints nothing.
-- Docs/image-only diffs, docstring-only Python diffs, and pytest test files (`test_*.py`, `*_test.py`, `conftest.py`) are exempt from the gate automatically.
-- Record the test baseline before coders start; without it, new breakage hides inside old noise.

package/skills/verified-build/SKILL.md

@@ -1,33 +0,0 @@
----
-name: verified-build
-description: >-
-  Two-phase verified workflow: scoped coder agents write the changes, then a
-  fresh-context code-verifier re-runs every check. Use for implementations,
-  refactors, and bug fixes. Triggers: 'verified build', 'run this verified',
-  'two-phase build', 'build and verify', 'verified implementation'.
----
-
-# Verified Build
-
-Two phases, hook-enforced: coders write, a fresh-context verifier grades, and `git commit`/`git push` open only on a clean verdict bound to the live change surface.
-
-## Workflow
-
-Copy this checklist and check items off as you go:
-
-- [ ] **Record baselines.** Before any coder runs: the test command and its exact failure set, plus any other gates the repo names. Scope the test command to the modules the task touches (their test files plus tests importing the changed modules); record a full-suite baseline only when the assignments span multiple modules or multiple coders. The verifier compares against these.
-- [ ] **Scope assignments.** Split the task into file-disjoint assignments; write each as a task text with named checks.
-- [ ] **Spawn coders.** One agent per assignment (`clean-coder` or Sonnet). Tell each: on a decision it can't reasonably solve, consult the tool-less `code-advisor` agent — it returns a plan, a correction, or a stop signal — then resume.
-- [ ] **Settle the tree.** After coders finish: run formatters and any file-rewriting hooks, stage nothing, change nothing more.
-- [ ] **Spawn the verifier last.** Agent tool, `subagent_type: "code-verifier"`, with the task texts, the diff scope, and the recorded baselines. When it stops, the SubagentStop hook mints its verdict.
-- [ ] **Repair only reported findings.** On a failing verdict, spawn repair agents scoped to the findings, then re-spawn the verifier. Repeat until clean.
-- [ ] **Land right away.** One commit, push, draft PR — before anything else touches a file.
-
-## Gotchas
-
-- Any file change after the verifier stops moves the surface hash and re-locks the gate — formatter rewrites included. Settle the tree first; land right after the clean verdict.
-- The verdict covers the whole branch surface (merge base to work tree, untracked files included). There is no "verify just my part."
-- The verifier must end with a ```` ```verdict ```` fence. No fence means nothing is minted and the gate stays closed.
-- The minter keys on the agent type string `code-verifier` — spawning the same prompt under another agent type mints nothing.
-- A surface whose every change is a docs/image file (by extension), a Python file whose docstring-stripped AST is unchanged (docstring-, comment-, or formatting-only Python edits), or a pytest test file (`test_*.py`, `*_test.py`, `conftest.py`) is exempt automatically; skip the verifier for those. Comment-only edits in non-Python files are not exempt.
-- Record the test baseline before coders start. Without the exact pre-existing failure set, new breakage hides inside old noise.