opencode-swarm 7.184.5 → 7.184.7

package/.opencode/skills/issue-tracer/SKILL.md

@@ -27,7 +27,7 @@ This contract is MANDATORY and blocking in every implementation mode. Closure is
 5. **Class eradication.** Phase 4.2 characterizes the defect class, sweeps the codebase, dispositions every hit, and installs a demonstrated guardrail.
 6. **Acceptance criteria closed.** Every acceptance criterion is re-verified at closure with concrete evidence.
 7. **Evidence over assertion, SHA-bound.** Every "passed"/"verified" claim cites command and output; every review verdict records the exact commit SHA and tree-id it examined, and closure requires the final approval identity to equal what ships.
-8. **Anti-tampering.** Once the Phase 2.5 red checkpoint is frozen, weakening, skipping, or deleting an acceptance check is a contract violation; any legitimate change goes through the checkpoint manifest as an `AMEND` row with a closed reason. `repro-check.sh` enforces three properties only - it refuses to re-freeze an already-frozen path, and it rejects a manifest whose row count differs from the count recorded in its header or whose `seq` column is not contiguous - which close deletion, truncation, reordering, and silent re-freeze. They are within-file, shape-only checks: editing a blob id in place, or deleting the manifest and re-running the freeze, is NOT detected, because nothing yet binds the file to anything outside the agent-writable trace directory. The manifest is evidence a reviewer re-runs and reads, never a mechanism that prevents weakening.
+8. **Anti-tampering.** Once the Phase 2.5 red checkpoint is frozen, weakening, skipping, or deleting an acceptance check is a contract violation; any legitimate change goes through the checkpoint manifest as an `AMEND` row with a closed reason. `repro-check.sh` enforces the manifest shape and emits an `anchor` receipt containing the no-filter manifest digest, the ordered acceptance-table semantic digest (`AC/class/check/argv/expect`), and the recorded `checkpoint-tree-id`. External publication of that receipt is a human-enforced gate outside the writable trace: `trace-check.sh` can validate only local structure and cannot attest that a receipt was published or when. A reviewer records the exact line after Phase 2.5, outside the trace, and later runs `verify-anchor` against that supplied literal. Editing a blob id or acceptance-table semantic field in place, or deleting/refreezing the manifest, therefore fails against the published receipt. A byte-identical refreeze remains valid by design. The manifest and table remain evidence a reviewer re-runs and reads; the external receipt is the non-circular identity anchor.
 
 ## Gate Table
 
@@ -38,9 +38,9 @@ This table is the normative center of the protocol: `trace-check.sh` reads it, a
 | 0 Setup | `state.md` | `trace-check.sh phase 0` | base SHA, tree-id, tier, freshness, and handshake recorded |
 | 1 Intake | `01-issue-summary.md` | `trace-check.sh phase 1` | classification set; acceptance criteria numbered; related issues listed |
 | 2 Reproduction + localization | `02-reproduction.md`, `03-localization-log.md`, `04-root-cause.md` | `trace-check.sh phase 2` | reproduction command + exit code + output; root cause at line/condition level |
-| 2.5 Acceptance checks (red checkpoint) | `## Acceptance checks` table in `02`, `repro/checkpoint.manifest` | `trace-check.sh phase 2.5` | every AC typed and checked; checkpoint tree-id recorded; diff from Phase 0 limited to manifest paths |
+| 2.5 Acceptance checks (red checkpoint) | `## Acceptance checks` table in `02`, `repro/checkpoint.manifest` | `trace-check.sh phase 2.5` | every AC typed and checked; manifest identities are `(path, check-id)` pairs, so multiple commands may freeze identical bytes from one file; checkpoint tree-id recorded; diff from Phase 0 limited to manifest paths; the external anchor publication is a human gate (not machine-verifiable by this validator) and must be confirmed before implementation |
 | 3 Plan + critic | `05-fix-plan.md`, `06-critic-review.md`, `07-approved-plan.md` | `trace-check.sh phase 3` | critic replays every frozen check; APPROVE recorded with both identities; user approval quoted |
-| 4 Implement + validate | `08-test-results.md` | `trace-check.sh phase 4` | every check RED-to-GREEN or GREEN-to-GREEN; checkpoint re-verified; `scan-deferred.sh` clean |
+| 4 Implement + validate | `08-test-results.md` | `trace-check.sh phase 4` | every check RED-to-GREEN or GREEN-to-GREEN; acceptance-table executable semantics match the manifest; checkpoint re-verified; `scan-deferred.sh` clean |
 | 4.2 Recurrence census | `08a-recurrence-sweep.md` | `trace-check.sh phase 4.2` | predicates counted; dispositions sum to counts; guardrail proven |
 | 4.5 Implementation review | `08b-implementation-review.md` | `trace-check.sh phase 4.5` | clean tree; independent APPROVE with `reviewed-commit` == HEAD |
 | 4.6 Final critic | `09-final-critic.md` | `trace-check.sh phase 4.6` | clean tree; APPROVE with both identities == current; every AC has evidence |

package/.opencode/skills/issue-tracer/assets/pr-template.md

@@ -32,6 +32,13 @@ This is a drafting aid. The published PR body must satisfy the repository's own
 - [Negative/boundary/adversarial case if relevant]
 - [Test drift review result]
 
+## External Checkpoint Anchor
+
+- Receipt published before implementation (human-confirmed; local validation cannot attest publication/timing): `issue-tracer-checkpoint-v1 slug=<slug> manifest=<40-hex> semantics=<40-hex> tree=<40-hex>`
+- External artifact location: [issue/PR/conversation URL or identifier]
+- Independent verification: `repro-check.sh verify-anchor --slug <slug> --receipt '<published literal>'` -> PASS
+- Local copy/provenance: [discovery copy path; explicitly non-authoritative]
+
 ## Acceptance Criteria -> Evidence
 
 | Acceptance criterion (from intake) | Evidence (command + output, or test name) |

package/.opencode/skills/issue-tracer/references/acceptance-checks.md

@@ -9,6 +9,13 @@ Use this reference for Phase 2.5 (freezing the checks) and Phase 4 (proving they
 3. Freeze the check set with `repro-check.sh checkpoint` before any production fix code exists. The checkpoint tree-id must differ from the Phase 0 tree-id only by paths listed in `repro/checkpoint.manifest` - this is validated mechanically at `trace-check.sh phase 2.5`.
 4. Phase 4 re-runs every check against the fixed tree; results are appended to the same table's `post-fix` column and echoed in `08-test-results.md`.
 
+The acceptance-table parser accepts either LF or CRLF line endings by removing
+only each record's terminal CR before matching the header and rows. Embedded
+C0/DEL control bytes (including controls in `AC`, `class`, `check`, `argv`,
+`expect`, or `notes`) and rows without exactly ten pipe-separated fields are
+rejected before any cell is used in a diagnostic. This keeps table validation
+and the semantic digest deterministic across Windows and POSIX checkouts.
+
 ## The three executable classes, plus NON-EXECUTABLE
 
 - **DISCRIMINATING** - behavior the bug breaks. Must be RED on the pre-fix tree for the expected reason (base exit nonzero and output matching `--expect`), GREEN after the fix. This is the class the bug-contrast replay rule applies to hardest.
@@ -26,17 +33,34 @@ Research measured that an agent's own generated tests overfit toward validating
 
 ## Red checkpoint manifest and amendment procedure
 
-`repro/checkpoint.manifest` lives in the git-excluded trace directory and is written only by `repro-check.sh checkpoint`; `repro-check.sh verify-checkpoint` replays it. The format is defined by the script itself: a `# issue-tracer checkpoint manifest v1 rows=<N>` header line, where `<N>` is the number of data rows and is restamped on every append, then one tab-separated row per frozen path with exactly ten fields - seq, kind (`CHECKPOINT` or `AMEND`), path, blob id, mode, check id, argv, expected regex, base SHA, and reason. Files are formatted with the repo's own formatter before hashing, and new checks live in their own new files (never appended to an existing file already at the 500-line test-file cap) so a later formatter pass does not silently change a frozen blob.
+`repro/checkpoint.manifest` lives in the git-excluded trace directory and is written only by `repro-check.sh checkpoint`; `repro-check.sh verify-checkpoint` replays it. The format is defined by the script itself: a `# issue-tracer checkpoint manifest v1 rows=<N>` header line, where `<N>` is the number of data rows and is restamped on every append, then one tab-separated row per checkpoint event with exactly ten fields - seq, kind (`CHECKPOINT` or `AMEND`), path, blob id, mode, check id, argv, expected regex, base SHA, and reason. Manifest identity is the `(path, check-id)` pair, so distinct checks may share a path when they capture the same current bytes. Files are formatted with the repo's own formatter before hashing, and new checks live in their own new files (never appended to an existing file already at the 500-line test-file cap) so a later formatter pass does not silently change a frozen blob.
+
+Four properties are mechanically enforced, by both `checkpoint` and `verify-checkpoint`. First, **a frozen pair cannot be re-frozen**: once a `(path, check-id)` pair appears in the manifest, a plain `repro-check.sh checkpoint` on that pair exits 2, while a different check id may checkpoint the same path only after hashing the current bytes. `verify-checkpoint` independently rejects any later row for the same pair that is not an `AMEND`, so a forged duplicate `CHECKPOINT` row is refused too, and an `AMEND` must name an existing exact pair. Second, **the effective manifest has one blob per path**: multiple check ids sharing a path are deduplicable only when their latest blobs are identical; divergent effective blobs fail closed instead of becoming path-only last-writer-wins. Third, **the recorded row count is validated**: the header's `rows=<N>` must equal the number of data rows actually present. Fourth, **seq continuity is validated**: the seq column must run 1..N with no gaps and every row must carry exactly ten fields. The count and seq checks are complementary and neither is sufficient alone - seq continuity is only a *prefix* invariant, so truncating the tail (`head -3`, or dropping the last row) leaves the survivors perfectly contiguous; the count is what catches that, and seq is what catches a deletion in the middle. Together they make deleting, truncating, reordering, duplicating, or mangling a row exit 2 in both commands instead of silently dropping that check out of the replay set.
+
+These row-shape properties do not by themselves inspect frozen content. The external checkpoint anchor below binds both content identity and the ordered acceptance-table semantics. Reviewers must retain the literal receipt emitted before implementation and verify it after the fix. The manifest and table remain agent-writable trace artifacts, so an in-place field edit, a semantic-table edit, a delete-and-refreeze, or a restamped state file is not independently authoritative; the old receipt is what makes those changes fail closed. A byte-identical refreeze is valid because it preserves the anchored digests and checkpoint tree id.
+
+So be precise about what is bought. The manifest-only rules close the ACCIDENTAL routes - a partial write, a botched hand edit, a truncating rewrite - and they close the one route that previously needed no editing at all: re-running the sanctioned freeze command to re-baseline a weakened check to green. A deliberate manifest edit or delete-and-refreeze fails when a reviewer verifies the pre-implementation external receipt. The plan critic and implementation reviewer still assess the semantic adequacy of the originally frozen checks; receipt verification does not make a weak check meaningful. Treat the manifest as a record to verify, never as a guarantee that its checks are adequate. A `v1` header with no `rows=` count is rejected outright for the same reason - accepting it for compatibility would itself be a one-line way to switch the count check off.
+
+Amending a frozen check (the check was wrong or the acceptance criterion changed) appends a new manifest entry rather than editing the old one, with a closed reason: `CHECK_WRONG` or `AC_CHANGED_BY_USER`. Both reasons require a fresh RED/GREEN replay before the amendment counts. Formatting changes to a frozen file are not a special exemption: use `CHECK_WRONG` or `AC_CHANGED_BY_USER` only when the check is genuinely being amended, then replay and review the result. The plan critic (before implementation) or the implementation reviewer (after) approves every amendment. Deleting or weakening a check to reach green, instead of amending it with a recorded reason, is a Full-Resolution Contract anti-tampering violation (clause 8).
 
-Three properties are mechanically enforced, by both `checkpoint` and `verify-checkpoint`. First, **a frozen path cannot be re-frozen**: once a path appears in the manifest, a plain `repro-check.sh checkpoint` on it exits 2, and `verify-checkpoint` independently rejects any later row for that path that is not an `AMEND` - so a forged `CHECKPOINT` row appended by hand is refused too, and the only way to supersede a frozen blob is an `AMEND` row carrying one of the closed reasons below, which stays in the file for the reviewer to read. Second, **the recorded row count is validated**: the header's `rows=<N>` must equal the number of data rows actually present. Third, **seq continuity is validated**: the seq column must run 1..N with no gaps and every row must carry exactly ten fields. The second and third are complementary and neither is sufficient alone - seq continuity is only a *prefix* invariant, so truncating the tail (`head -3`, or dropping the last row) leaves the survivors perfectly contiguous; the count is what catches that, and seq is what catches a deletion in the middle. Together they make deleting, truncating, reordering, duplicating, or mangling a row exit 2 in both commands instead of silently dropping that check out of the replay set - and, because a truncated-away path would otherwise no longer count as frozen, they are also what keeps the first property from being reopened by a truncation.
+## External checkpoint anchor
 
-These three properties are cardinality-and-shape checks. They never inspect row CONTENT, and that limit is the most important thing to understand about this artifact. **Editing a field of an existing row in place is not detected at all.** Replacing the blob id of a frozen row with the hash of a weakened file leaves `rows=<N>` correct, `seq` contiguous, ten fields intact, no `AMEND` row and no new line - a structurally pristine manifest - and `verify-checkpoint` then prints `OK` and exits 0. That is a single `sed`. Worse, the checks are all *within-file* invariants - nothing binds the manifest's existence or completeness to anything outside it - so deleting the manifest (or blanking it back to a `rows=0` header) and re-running the sanctioned `repro-check.sh checkpoint` re-freezes every path against whatever the files contain now, exits 0, and leaves a structurally pristine manifest that `verify-checkpoint` and Phase 2.5 both accept. No editing of any row is required.
+After the final Phase-2.5 checkpoint and before any production edit, run `repro-check.sh anchor --slug <slug>`. It first verifies the manifest and that every executable table row's `check`, `argv`, and `expect` matches the effective manifest, then emits exactly one line in this shape:
 
-Closing this needs an anchor the manifest itself does not supply, and none is implemented yet. A hash stored beside the manifest is circular - the trace directory is the agent's own write surface, deliberately excluded from `tree-id` and from the dirty-tree gate, so the same hand writes both. The most promising in-band candidate is the `checkpoint-tree-id` already recorded in `state.md` and cross-checked at Phase 2.5: it is a content-addressed git tree, so each manifest blob id could be compared against `git rev-parse "<checkpoint-tree-id>:<path>"`, which would catch an in-place edit and a delete-and-re-freeze alike. It is not circular in the accidental case and raises cost in the adversarial one, though an agent that also restamps `checkpoint-tree-id` still gets through. A fully non-circular anchor has to live outside the agent's reach entirely - the manifest hash published in the PR body, a git note, or a CI artifact at freeze time. Both options are tracked in the follow-up issue; until one lands, treat the manifest accordingly.
+```text
+issue-tracer-checkpoint-v1 slug=<slug> manifest=<40-hex manifest blob> semantics=<40-hex acceptance-table digest> tree=<40-hex checkpoint-tree-id>
+```
 
-So be precise about what is bought. These rules close the ACCIDENTAL routes - a partial write, a botched hand edit, a truncating rewrite - and they close the one route that previously needed no editing at all: re-running the sanctioned freeze command to re-baseline a weakened check to green. They do not raise a meaningful barrier against an agent that deliberately edits the file. Treat the manifest as a record a reviewer must independently re-run and read, never as a guarantee that the checks it lists are the checks that were frozen. Detecting a deliberate weakening remains the plan critic's and implementation reviewer's job. A `v1` header with no `rows=` count is rejected outright for the same reason - accepting it for compatibility would itself be a one-line way to switch the count check off.
+The implementation owner publishes that literal in the issue, PR, or other reviewer-visible external conversation and records the artifact location in the trace as a non-authoritative discovery copy. Publication and its before/after timing are human-enforced: `trace-check.sh` cannot observe that external conversation. The owner must not regenerate it after implementation begins. An independent reviewer copies the published literal into `repro-check.sh verify-anchor --slug <slug> --receipt '<literal>'`; verification compares the current manifest digest, the current ordered `AC/class/check/argv/expect` digest, and `state.md`'s recorded `checkpoint-tree-id`. It deliberately does not compare the live working-tree tree, which changes as the fix is implemented. Malformed, stale, tampered, semantic-table-edited, or delete-and-refreeze evidence fails closed; a byte-identical refreeze remains valid because it has the same content identity.
 
-Amending a frozen check (the check was wrong, or a formatter-only touch changed its blob) appends a new manifest entry rather than editing the old one, with a closed reason: `CHECK_WRONG`, `FORMAT_ONLY`, or `AC_CHANGED_BY_USER`. `CHECK_WRONG` and `AC_CHANGED_BY_USER` require a fresh RED/GREEN replay before the amendment counts; `FORMAT_ONLY` is defined as behavior-preserving and so skips the replay. Note that the `reason` field is asserted by the writer and never verified: a semantic weakening labelled `FORMAT_ONLY` supersedes a frozen blob and skips the replay in one sanctioned command. The reviewer therefore checks every `FORMAT_ONLY` row against the actual blob diff rather than accepting the label. The plan critic (before implementation) or the implementation reviewer (after) approves every amendment. Deleting or weakening a check to reach green, instead of amending it with a recorded reason, is a Full-Resolution Contract anti-tampering violation (clause 8).
+Receipt compatibility is intentionally strict: the pre-semantics receipt
+syntax (the same `issue-tracer-checkpoint-v1` prefix without a `semantics=`
+field) is rejected as `malformed anchor receipt`. There is no safe migration
+or placeholder digest, because that old receipt never bound the acceptance
+table's `AC/class/check/argv/expect` semantics. A trace with only an old
+receipt must be rechecked and re-anchored before implementation; once
+implementation has begun, stop and obtain a new reviewed checkpoint rather
+than regenerating the receipt silently.
 
 ## Dependency strategy
 

package/.opencode/skills/issue-tracer/references/critic-gate.md

@@ -30,6 +30,8 @@ Read these artifacts:
 
 Also inspect any files referenced in the plan. Do not trust summaries if the underlying code is available. Independently replay the frozen acceptance checks yourself (`repro-check.sh run` for each row) before returning a verdict - do not accept the table's pre-fix column on faith.
 
+When a checkpoint anchor exists, independently compare the externally published receipt with `repro-check.sh verify-anchor --slug <slug> --receipt '<literal>'`; this verifies the local manifest/table/tree digests only, while publication and its timing remain a human gate that the validator cannot observe. Do not accept a receipt regenerated after implementation began.
+
 Return exactly:
 
 # Critic Review
@@ -159,6 +161,8 @@ Find, with concrete evidence:
 - independently re-run every acceptance check yourself with `repro-check.sh run` on both the pre-fix and current trees
 - verify `repro-check.sh verify-checkpoint`, scan for tautological checks, and (at tier M/L, any risk trigger, or any NEW-SURFACE row) run the revert/mutation probe from `references/acceptance-checks.md`
 
+When a checkpoint anchor exists, independently compare the externally published receipt with `repro-check.sh verify-anchor --slug <slug> --receipt '<literal>'`; this verifies the local manifest/table/tree digests only, while publication and its timing remain a human gate that the validator cannot observe. Do not accept a receipt regenerated after implementation began.
+
 Return exactly:
 
 # Implementation Review
@@ -240,6 +244,7 @@ Check:
 - every acceptance criterion maps to concrete evidence
 - validation claims are backed by commands and output
 - no work was silently deferred, scoped out, or left unwired
+- if a checkpoint anchor exists, verify the externally published literal with `repro-check.sh verify-anchor` and record human confirmation that it was published before implementation (the local validator cannot verify publication or timing)
 
 Return exactly:
 

package/.opencode/skills/issue-tracer/references/evidence-artifacts.md

@@ -105,13 +105,29 @@ Gate rows (`plan-critic`, `implementation-review`, `final-critic`, `merge-approv
 |---|---|---|---|---|---|---|---|
 | AC1 | DISCRIMINATING / PRESERVING / NEW-SURFACE / NON-EXECUTABLE | C1 or DOCS_ONLY/HOST_ONLY/PRODUCT_DECISION/EXTERNAL_SERVICE_UNAVAILABLE | `<command>` or `-` | `<regex>` or `-` | RED / GREEN / ERROR / `-` | GREEN or `pending` | [substitute evidence path or free text] |
 
-The table splits each row on `|`, so the `argv` cell must never contain a literal `|` (for example a shell pipeline). If a check needs a pipeline, write it as a small script under `repro/` and put the script's path/invocation in `argv` instead of the raw pipeline. `trace-check.sh` rejects any row with more than 8 cells with `FAIL acceptance-table-row-ACn: row for ACn has too many columns (literal | in argv?)`.
+The table splits each row on `|`, so the `argv` cell must never contain a literal `|` (for example a shell pipeline). If a check needs a pipeline, write it as a small script under `repro/` and put the script's path/invocation in `argv` instead of the raw pipeline. Rows must have exactly ten pipe-separated fields, including the leading and trailing delimiters; missing a final delimiter is malformed just like an extra delimiter. The parser accepts LF and CRLF line endings by stripping only each record's terminal CR, while embedded C0/DEL control bytes in any cell are rejected before diagnostics. `trace-check.sh` reports the row shape/control failure without interpolating the untrusted cell.
 
 ## Red checkpoint
 manifest: repro/checkpoint.manifest
 checkpoint-tree-id: <40-hex>
 ```
 
+## External checkpoint anchor
+
+After the final Phase-2.5 checkpoint and before production edits, the implementation owner runs `repro-check.sh anchor --slug <slug>` and publishes the exact one-line receipt in an external, reviewer-visible issue or PR conversation. This publication and its timing are a human-enforced gate; the local validator cannot attest to either. The receipt has no secrets or source content:
+
+```text
+issue-tracer-checkpoint-v1 slug=<slug> manifest=<40-hex manifest blob> semantics=<40-hex acceptance-table digest> tree=<40-hex checkpoint-tree-id>
+```
+
+Record the publication URL or conversation identifier and a verbatim discovery copy in the trace, but never treat that local copy as authority. The owner must not regenerate the receipt after implementation begins. Independent reviewers verify the externally copied literal with `repro-check.sh verify-anchor --slug <slug> --receipt '<literal>'`; verification uses the no-filter manifest digest, the ordered acceptance-table semantic digest, and the `checkpoint-tree-id` recorded in `state.md`, not the live working-tree tree. Any malformed, stale, in-place-edited, semantic-table-edited, or delete-and-refrozen manifest fails closed. A byte-identical refreeze is intentionally accepted.
+
+Receipts emitted before the `semantics=` field was introduced are not
+compatible with this schema and are rejected as malformed. No migration is
+provided: an old receipt cannot prove that the acceptance table was frozen,
+so a pre-implementation trace must be rechecked and re-anchored, while a
+trace already under implementation must not silently regenerate its anchor.
+
 ## `03-localization-log.md`
 
 ```markdown
@@ -361,7 +377,7 @@ Written when CI rounds occur after publication: one entry per round with the fai
 
 ## `repro/` layout
 
-Lives inside the trace directory (git-excluded, never committed): `checkpoint.manifest` (rows are appended, never edited - a frozen path is superseded only by a recorded `AMEND` row, and both the header's recorded row count and `seq` continuity are validated on every read and write; header `# issue-tracer checkpoint manifest v1 rows=<N>`, restamped with the row and seeded by `trace-init.sh` as `rows=0`, and see `references/acceptance-checks.md` for what that does and does not guarantee) plus `<check-id>.base.log` and `<check-id>.head.log` per executable check, written by `repro-check.sh run`.
+Lives inside the trace directory (git-excluded, never committed): `checkpoint.manifest` (rows are appended, never edited - a frozen `(path, check-id)` pair is superseded only by a recorded `AMEND` row, while distinct check ids may share a path only when they capture identical current bytes; divergent effective blobs for one path fail closed, and both the header's recorded row count and `seq` continuity are validated on every read and write; header `# issue-tracer checkpoint manifest v1 rows=<N>`, restamped with the row and seeded by `trace-init.sh` as `rows=0`, and see `references/acceptance-checks.md` for what that does and does not guarantee) plus `<check-id>.base.log` and `<check-id>.head.log` per executable check, written by `repro-check.sh run`.
 
 ## OBE subset