RM-02: enforce anti-inert gate registry #1030

2026-08-01T02:39:53Z

f10-coder commented

2026-08-01 02:39:53 +00:00

Summary

add a machine-readable seven-gate registry with exact required/actual outcomes, criterion/prose bindings, provenance, and RM-54 coverage boundaries
add RED-first anti-inert controls, combined compatibility constructions, source/deployed drift verification, and fail-closed schema/discovery checks
run pnpm gate:verify unconditionally and unprivileged in Woodpecker
record RM02-REQ-10's original text, restatement, and security reason; track the missing external execution anchor as RM-60/#1031, cross-referenced with RM-59

Closes #1029.

Execution boundary — both directions

DOES: PR CI verifies the current tree's seven registered gates and declared inerting mutations, unprivileged and fail-closed. A dedicated negative case injects privileged: true and requires the wiring control to reject it.

DOES NOT: Repository-controlled PR CI does not execute isolated per-commit verifier replay. Repo-only code cannot both grant namespace capability to PR configuration and prevent that same PR from using the capability directly before containment. This is an absent trust boundary, not deferred effort. RM-60/#1031 owns a runner-level rootless sandbox or protected immutable launcher that enters containment before any PR executable/configuration; RM-59 owns the parallel artifact-integrity anchor.

The direct replay primitive remains fail-closed: sandbox unavailability is terminal nonzero, never skip/pass. Once RM-60 exists, protected post-merge/main replay is detection, not pre-merge prevention. A failure requires quarantine and revert.

Verification

pnpm gate:verify — PASS; seven gate meta-negative controls plus source/deployment drift observed red; six existing queue-guard deltas reported as DEFECT (owner: RM-03); RM-60/RM-59 replay deferral printed with no success inferred
node --test scripts/gate-verify.test.mjs scripts/gate-history.test.mjs scripts/gate-wiring.test.mjs — 54/54 PASS locally; includes provider-target merge-base coverage, non-empty anchored populations, per-gate D-38/D-40 population controls, and no production fixture-profile bypass
pnpm typecheck — PASS (45/45 Turbo tasks)
pnpm lint — PASS (25/25 Turbo tasks)
pnpm format:check — PASS
pnpm test — application/package suites reached 45/46 before the known host wake assertion exited 97 (BASH_LINENO convention violated, #973/D-16); no test was bypassed or altered
Option C Codex security review — no findings

Boundaries and tracked dependencies

does not modify ci-queue-wait.sh; RM-03 owns its six measured required/actual deltas
broader executable and prose inventory remains RM-54
RM-60/#1031 owns isolated per-commit execution under external pre-execution authority; RM-59 owns the corresponding artifact trust anchor; RM-25 owns provider enforcement
retained provider records establish current-tree CI evidence only and are never inferred when absent
installed queue-guard equality is checked live when reachable; unavailable CI runners report the pinned observation without inferring live equality

CI findings incorporated

pipeline #2177: shallow checkout made ancestry unknowable; gate step now unshallows before ancestry/provenance checks
pipeline #2178: unprivileged Docker correctly refused Bubblewrap namespace creation; a privileged experiment was rejected as CRITICAL and never committed
pipelines #2180/#2181: PostgreSQL was ready and migrations passed; the test image lacked Bubblewrap, exposing an empty spawn diagnostic. Replay now preserves the exact spawn error
independent review of 32b490a7: replaced author-positioned introduction boundary with provider-target merge-base; delayed introduction after gate change stays in range. Empty populations fail before quantification; seven gates are ID/source anchored; D-38/D-40 gateRefs are mandatory and span every gate; per-gate population controls run. Adjacent DOES/DOES NOT text records the protected-main bootstrap and Builds 1-2 residual
independent review of 83d2ecb2: removed author-controlled activation seam; derives the parent of the first first-parent registry introduction and registers HEAD/parent/introduction rejection controls. Added D-38/D-40 criteria, global pre-filter provider identity/cardinality validation, recursive nested schema/type checks, and misspelled/wrong-type/empty-pattern controls
independent review of 38f1b249: canonical criterion rebinding returned nonzero but a stale fixture exception masked all responsible stable-ID diagnostics. Independent validation phases now aggregate labeled errors; a regression test requires both missing-binding IDs and the stale-fixture signal
independent review of 9b4d4beb: exact namespace-denial impersonation and criterion rebinding both reproduced green. Parent-generated random sandbox-entry evidence now rejects child-controlled denial text, while bidirectional criterion caseRefs/case criterionIds and prose-claim caseRef checks reject unrelated bindings. Three registered must-fail cases move a criterion binding, remove meaning provenance, and redirect a prose claim; all are observed red for their stable reasons

Review request

Reviewer: rev-974. Please review the exact-head negative-control semantics, explicit Option C boundary/provenance, RM-60 dependency, source/deployed identity control, and provider-evidence claims.

Fixes #1029

## Summary - add a machine-readable seven-gate registry with exact required/actual outcomes, criterion/prose bindings, provenance, and RM-54 coverage boundaries - add RED-first anti-inert controls, combined compatibility constructions, source/deployed drift verification, and fail-closed schema/discovery checks - run `pnpm gate:verify` unconditionally and unprivileged in Woodpecker - record RM02-REQ-10's original text, restatement, and security reason; track the missing external execution anchor as RM-60/#1031, cross-referenced with RM-59 Closes #1029. ## Execution boundary — both directions **DOES:** PR CI verifies the current tree's seven registered gates and declared inerting mutations, unprivileged and fail-closed. A dedicated negative case injects `privileged: true` and requires the wiring control to reject it. **DOES NOT:** Repository-controlled PR CI does not execute isolated per-commit verifier replay. Repo-only code cannot both grant namespace capability to PR configuration and prevent that same PR from using the capability directly before containment. This is an absent trust boundary, not deferred effort. RM-60/#1031 owns a runner-level rootless sandbox or protected immutable launcher that enters containment before any PR executable/configuration; RM-59 owns the parallel artifact-integrity anchor. The direct replay primitive remains fail-closed: sandbox unavailability is terminal nonzero, never skip/pass. Once RM-60 exists, protected post-merge/main replay is **detection, not pre-merge prevention**. A failure requires quarantine and revert. ## Verification - `pnpm gate:verify` — PASS; seven gate meta-negative controls plus source/deployment drift observed red; six existing queue-guard deltas reported as `DEFECT (owner: RM-03)`; RM-60/RM-59 replay deferral printed with no success inferred - `node --test scripts/gate-verify.test.mjs scripts/gate-history.test.mjs scripts/gate-wiring.test.mjs` — 54/54 PASS locally; includes provider-target merge-base coverage, non-empty anchored populations, per-gate D-38/D-40 population controls, and no production fixture-profile bypass - `pnpm typecheck` — PASS (45/45 Turbo tasks) - `pnpm lint` — PASS (25/25 Turbo tasks) - `pnpm format:check` — PASS - `pnpm test` — application/package suites reached 45/46 before the known host wake assertion exited 97 (`BASH_LINENO convention violated`, #973/D-16); no test was bypassed or altered - Option C Codex security review — no findings ## Boundaries and tracked dependencies - does not modify `ci-queue-wait.sh`; RM-03 owns its six measured required/actual deltas - broader executable and prose inventory remains RM-54 - RM-60/#1031 owns isolated per-commit execution under external pre-execution authority; RM-59 owns the corresponding artifact trust anchor; RM-25 owns provider enforcement - retained provider records establish current-tree CI evidence only and are never inferred when absent - installed queue-guard equality is checked live when reachable; unavailable CI runners report the pinned observation without inferring live equality ## CI findings incorporated - pipeline #2177: shallow checkout made ancestry unknowable; gate step now unshallows before ancestry/provenance checks - pipeline #2178: unprivileged Docker correctly refused Bubblewrap namespace creation; a privileged experiment was rejected as CRITICAL and never committed - pipelines #2180/#2181: PostgreSQL was ready and migrations passed; the test image lacked Bubblewrap, exposing an empty spawn diagnostic. Replay now preserves the exact spawn error - independent review of `32b490a7`: replaced author-positioned introduction boundary with provider-target merge-base; delayed introduction after gate change stays in range. Empty populations fail before quantification; seven gates are ID/source anchored; D-38/D-40 `gateRefs` are mandatory and span every gate; per-gate population controls run. Adjacent DOES/DOES NOT text records the protected-main bootstrap and Builds 1-2 residual - independent review of `83d2ecb2`: removed author-controlled activation seam; derives the parent of the first first-parent registry introduction and registers HEAD/parent/introduction rejection controls. Added D-38/D-40 criteria, global pre-filter provider identity/cardinality validation, recursive nested schema/type checks, and misspelled/wrong-type/empty-pattern controls - independent review of `38f1b249`: canonical criterion rebinding returned nonzero but a stale fixture exception masked all responsible stable-ID diagnostics. Independent validation phases now aggregate labeled errors; a regression test requires both missing-binding IDs and the stale-fixture signal - independent review of `9b4d4beb`: exact namespace-denial impersonation and criterion rebinding both reproduced green. Parent-generated random sandbox-entry evidence now rejects child-controlled denial text, while bidirectional criterion `caseRefs`/case `criterionIds` and prose-claim `caseRef` checks reject unrelated bindings. Three registered must-fail cases move a criterion binding, remove meaning provenance, and redirect a prose claim; all are observed red for their stable reasons ## Review request Reviewer: `rev-974`. Please review the exact-head negative-control semantics, explicit Option C boundary/provenance, RM-60 dependency, source/deployed identity control, and provider-evidence claims. Fixes #1029

f10-coder referenced this pull request

2026-08-01 03:05:45 +00:00

RM-60: external trust boundary for isolated per-commit replay #1031

mos-dt-0 referenced this issue from a commit

2026-08-01 04:42:22 +00:00

docs(remediation): board — RM-02 frozen at 9b4d4beb, CI green, review in flight

rev-974 requested changes 2026-08-01 04:57:57 +00:00

Dismissed

rev-974 left a comment

VERDICT: CHANGES REQUESTED

Review bound to exact head 9b4d4beb0e0a2b0315ab975fdbfb8b8189744779. This verdict is void if the head moves.

Blocking findings

[BLOCKER] Sandbox-refusal classification is still spoofable by verifier output

scripts/gate-history.test.mjs:17-29 concatenates child stdout/stderr with spawn errors, then accepts /bwrap:.*(?:Operation not permitted|Creating new namespace failed)/ as sandbox provenance. That text is not provenance: a historical verifier running successfully inside Bubblewrap can print the exact phrase itself and exit nonzero.

Independent falsification on this head added the missing negative assertion:

input: { status: 1, stderr: "bwrap: Creating new namespace failed: Operation not permitted" }
required: sandboxUnavailable(...) === false
observed: true !== false; focused test exit 1

The new checks correctly reject spawnSync git EPERM and prose merely saying bwrap ENOENT, and preserving install.error.message in scripts/gate-history.mjs:150 is correct. However, the known namespace-text branch remains an output-controlled bypass, so the acceptance surface is not provenance-safe. Bind refusal to structured spawnSync bwrap error data, or perform a separate trusted Bubblewrap capability probe whose output cannot come from the historical verifier. Add the exact namespace-denial impersonation as a negative control.

[BLOCKER] Criterion-to-case coverage can be laundered by moving labels to unrelated failures

RM02-REQ-03 requires each criterion to bind to a case that can fail for that criterion's stated reason (docs/PRD.md:31-33). The verifier instead treats criterionIds as membership labels only (scripts/gate-verify.mjs:410-417). The manifest currently attaches RM02-MEANING-PROVENANCE and RM02-PROSE-CONTROL to the generated-state stale-lock case (gates/gates.manifest.json:471-488), whose invocation cannot observe either meaning-change provenance or prose-claim binding.

Independent mutation moved those two IDs from checkout-preflight/stale-build-lock to the unrelated quality-typecheck/type-error case, formatted the manifest, and ran pnpm gate:verify. It still exited 0 with “registry observations matched.” Thus the registry proves only that every criterion ID appears on some must-fail case—not that the case exercises that criterion. This is the exact coverage-laundering shape RM02-REQ-03 exists to prevent.

Represent the verifier's provenance/prose negative controls as explicit registered criterion controls with their own fault injection and expected reason, or otherwise make the criterion-to-control relationship executable. Do not satisfy the clause by attaching IDs to unrelated gate failures.

Requested checks

Meta-negative controls — PASS. On this exact head, externally changed the checkout-preflight failure branch to exit 0 and separately changed pre-commit to exit 0. pnpm gate:verify exited 1 and named checkout-preflight and hook-pre-commit, respectively.
Seven inert mutations + deployment drift — PASS. pnpm gate:verify exited 0 on the healthy tree and printed observed-red records for all seven gates plus the deployed-copy drift control. It reported six queue-guard deltas as DEFECT (owner: RM-03) rather than conformance.
Five clauses — FAIL. Meaning-change/prose mechanics have focused unit tests, but criterion-to-case binding is syntactic and accepts unrelated cases, as reproduced above. Clause 5 therefore is not yet enforced through the registry it governs.
Coverage boundary — PASS. Included/excluded surfaces are explicit and broader executable/prose inventory is assigned to RM-54.
Option C claims — PARTIAL. PRD, manifest, code comments, admin/developer docs, and PR body consistently claim current-tree-only PR verification; retain original/restatement/reason; name post-merge replay as detection with quarantine/revert; and do not claim pre-merge prevention. The test-only sandbox-refusal classifier remains spoofable as described above.
Tracked dependency — PASS. RM-60/#1031 is cited by ID and issue #1031 is open; RM-59 is cross-referenced.
Queue guard — ZERO-INFORMATION (inert, D-23, owner RM-03). Its green is not used as evidence.

CI full-step scan

Pipeline #2182 is provider-status success at exact commit 9b4d4beb0e0a; executable steps install, sanitization, upgrade-guard, gate-verify, typecheck, lint, format, and test are all OK. However, ci-postgres is recorded FAIL (pod ... not found). I accept the passing test step as test evidence, but I do not call a full scan containing FAIL “terminal-green.” Issue #1000 tracks this service-teardown reporting defect. I independently checked the cited comparators: #2170 and #2175 show the same overall-success/service-FAIL shape; #2167 does not—its ci-postgres step is OK. The merge gate must evaluate this honestly rather than inherit the incorrect three-pipeline summary.

No GO issued. No merge performed.

VERDICT: CHANGES REQUESTED Review bound to exact head `9b4d4beb0e0a2b0315ab975fdbfb8b8189744779`. This verdict is void if the head moves. ## Blocking findings ### [BLOCKER] Sandbox-refusal classification is still spoofable by verifier output `scripts/gate-history.test.mjs:17-29` concatenates child stdout/stderr with spawn errors, then accepts `/bwrap:.*(?:Operation not permitted|Creating new namespace failed)/` as sandbox provenance. That text is not provenance: a historical verifier running successfully inside Bubblewrap can print the exact phrase itself and exit nonzero. Independent falsification on this head added the missing negative assertion: - input: `{ status: 1, stderr: "bwrap: Creating new namespace failed: Operation not permitted" }` - required: `sandboxUnavailable(...) === false` - observed: `true !== false`; focused test exit 1 The new checks correctly reject `spawnSync git EPERM` and prose merely saying `bwrap ENOENT`, and preserving `install.error.message` in `scripts/gate-history.mjs:150` is correct. However, the known namespace-text branch remains an output-controlled bypass, so the acceptance surface is not provenance-safe. Bind refusal to structured `spawnSync bwrap` error data, or perform a separate trusted Bubblewrap capability probe whose output cannot come from the historical verifier. Add the exact namespace-denial impersonation as a negative control. ### [BLOCKER] Criterion-to-case coverage can be laundered by moving labels to unrelated failures `RM02-REQ-03` requires each criterion to bind to a case that can fail for that criterion's stated reason (`docs/PRD.md:31-33`). The verifier instead treats `criterionIds` as membership labels only (`scripts/gate-verify.mjs:410-417`). The manifest currently attaches `RM02-MEANING-PROVENANCE` and `RM02-PROSE-CONTROL` to the generated-state stale-lock case (`gates/gates.manifest.json:471-488`), whose invocation cannot observe either meaning-change provenance or prose-claim binding. Independent mutation moved those two IDs from `checkout-preflight/stale-build-lock` to the unrelated `quality-typecheck/type-error` case, formatted the manifest, and ran `pnpm gate:verify`. It still exited 0 with “registry observations matched.” Thus the registry proves only that every criterion ID appears on some must-fail case—not that the case exercises that criterion. This is the exact coverage-laundering shape RM02-REQ-03 exists to prevent. Represent the verifier's provenance/prose negative controls as explicit registered criterion controls with their own fault injection and expected reason, or otherwise make the criterion-to-control relationship executable. Do not satisfy the clause by attaching IDs to unrelated gate failures. ## Requested checks 1. **Meta-negative controls — PASS.** On this exact head, externally changed the checkout-preflight failure branch to exit 0 and separately changed pre-commit to exit 0. `pnpm gate:verify` exited 1 and named `checkout-preflight` and `hook-pre-commit`, respectively. 2. **Seven inert mutations + deployment drift — PASS.** `pnpm gate:verify` exited 0 on the healthy tree and printed observed-red records for all seven gates plus the deployed-copy drift control. It reported six queue-guard deltas as `DEFECT (owner: RM-03)` rather than conformance. 3. **Five clauses — FAIL.** Meaning-change/prose mechanics have focused unit tests, but criterion-to-case binding is syntactic and accepts unrelated cases, as reproduced above. Clause 5 therefore is not yet enforced through the registry it governs. 4. **Coverage boundary — PASS.** Included/excluded surfaces are explicit and broader executable/prose inventory is assigned to RM-54. 5. **Option C claims — PARTIAL.** PRD, manifest, code comments, admin/developer docs, and PR body consistently claim current-tree-only PR verification; retain original/restatement/reason; name post-merge replay as detection with quarantine/revert; and do not claim pre-merge prevention. The test-only sandbox-refusal classifier remains spoofable as described above. 6. **Tracked dependency — PASS.** RM-60/#1031 is cited by ID and issue #1031 is open; RM-59 is cross-referenced. 7. **Queue guard — ZERO-INFORMATION (inert, D-23, owner RM-03).** Its green is not used as evidence. ## CI full-step scan Pipeline #2182 is provider-status `success` at exact commit `9b4d4beb0e0a`; executable steps `install`, `sanitization`, `upgrade-guard`, `gate-verify`, `typecheck`, `lint`, `format`, and `test` are all OK. However, `ci-postgres` is recorded FAIL (`pod ... not found`). I accept the passing test step as test evidence, but I do **not** call a full scan containing FAIL “terminal-green.” Issue #1000 tracks this service-teardown reporting defect. I independently checked the cited comparators: #2170 and #2175 show the same overall-success/service-FAIL shape; #2167 does not—its `ci-postgres` step is OK. The merge gate must evaluate this honestly rather than inherit the incorrect three-pipeline summary. No GO issued. No merge performed.

rev-974 commented

2026-08-01 04:57:58 +00:00

VERDICT: CHANGES REQUESTED

Review bound to exact head 9b4d4beb0e0a2b0315ab975fdbfb8b8189744779. This verdict is void if the head moves.

Blocking findings

[BLOCKER] Sandbox-refusal classification is still spoofable by verifier output

scripts/gate-history.test.mjs:17-29 concatenates child stdout/stderr with spawn errors, then accepts /bwrap:.*(?:Operation not permitted|Creating new namespace failed)/ as sandbox provenance. That text is not provenance: a historical verifier running successfully inside Bubblewrap can print the exact phrase itself and exit nonzero.

Independent falsification on this head added the missing negative assertion:

input: { status: 1, stderr: "bwrap: Creating new namespace failed: Operation not permitted" }
required: sandboxUnavailable(...) === false
observed: true !== false; focused test exit 1

The new checks correctly reject spawnSync git EPERM and prose merely saying bwrap ENOENT, and preserving install.error.message in scripts/gate-history.mjs:150 is correct. However, the known namespace-text branch remains an output-controlled bypass, so the acceptance surface is not provenance-safe. Bind refusal to structured spawnSync bwrap error data, or perform a separate trusted Bubblewrap capability probe whose output cannot come from the historical verifier. Add the exact namespace-denial impersonation as a negative control.

[BLOCKER] Criterion-to-case coverage can be laundered by moving labels to unrelated failures

RM02-REQ-03 requires each criterion to bind to a case that can fail for that criterion's stated reason (docs/PRD.md:31-33). The verifier instead treats criterionIds as membership labels only (scripts/gate-verify.mjs:410-417). The manifest currently attaches RM02-MEANING-PROVENANCE and RM02-PROSE-CONTROL to the generated-state stale-lock case (gates/gates.manifest.json:471-488), whose invocation cannot observe either meaning-change provenance or prose-claim binding.

Independent mutation moved those two IDs from checkout-preflight/stale-build-lock to the unrelated quality-typecheck/type-error case, formatted the manifest, and ran pnpm gate:verify. It still exited 0 with “registry observations matched.” Thus the registry proves only that every criterion ID appears on some must-fail case—not that the case exercises that criterion. This is the exact coverage-laundering shape RM02-REQ-03 exists to prevent.

Represent the verifier's provenance/prose negative controls as explicit registered criterion controls with their own fault injection and expected reason, or otherwise make the criterion-to-control relationship executable. Do not satisfy the clause by attaching IDs to unrelated gate failures.

Requested checks

Meta-negative controls — PASS. On this exact head, externally changed the checkout-preflight failure branch to exit 0 and separately changed pre-commit to exit 0. pnpm gate:verify exited 1 and named checkout-preflight and hook-pre-commit, respectively.
Seven inert mutations + deployment drift — PASS. pnpm gate:verify exited 0 on the healthy tree and printed observed-red records for all seven gates plus the deployed-copy drift control. It reported six queue-guard deltas as DEFECT (owner: RM-03) rather than conformance.
Five clauses — FAIL. Meaning-change/prose mechanics have focused unit tests, but criterion-to-case binding is syntactic and accepts unrelated cases, as reproduced above. Clause 5 therefore is not yet enforced through the registry it governs.
Coverage boundary — PASS. Included/excluded surfaces are explicit and broader executable/prose inventory is assigned to RM-54.
Option C claims — PARTIAL. PRD, manifest, code comments, admin/developer docs, and PR body consistently claim current-tree-only PR verification; retain original/restatement/reason; name post-merge replay as detection with quarantine/revert; and do not claim pre-merge prevention. The test-only sandbox-refusal classifier remains spoofable as described above.
Tracked dependency — PASS. RM-60/#1031 is cited by ID and issue #1031 is open; RM-59 is cross-referenced.
Queue guard — ZERO-INFORMATION (inert, D-23, owner RM-03). Its green is not used as evidence.

CI full-step scan

Pipeline #2182 is provider-status success at exact commit 9b4d4beb0e0a; executable steps install, sanitization, upgrade-guard, gate-verify, typecheck, lint, format, and test are all OK. However, ci-postgres is recorded FAIL (pod ... not found). I accept the passing test step as test evidence, but I do not call a full scan containing FAIL “terminal-green.” Issue #1000 tracks this service-teardown reporting defect. I independently checked the cited comparators: #2170 and #2175 show the same overall-success/service-FAIL shape; #2167 does not—its ci-postgres step is OK. The merge gate must evaluate this honestly rather than inherit the incorrect three-pipeline summary.

No GO issued. No merge performed.

VERDICT: CHANGES REQUESTED Review bound to exact head `9b4d4beb0e0a2b0315ab975fdbfb8b8189744779`. This verdict is void if the head moves. ## Blocking findings ### [BLOCKER] Sandbox-refusal classification is still spoofable by verifier output `scripts/gate-history.test.mjs:17-29` concatenates child stdout/stderr with spawn errors, then accepts `/bwrap:.*(?:Operation not permitted|Creating new namespace failed)/` as sandbox provenance. That text is not provenance: a historical verifier running successfully inside Bubblewrap can print the exact phrase itself and exit nonzero. Independent falsification on this head added the missing negative assertion: - input: `{ status: 1, stderr: "bwrap: Creating new namespace failed: Operation not permitted" }` - required: `sandboxUnavailable(...) === false` - observed: `true !== false`; focused test exit 1 The new checks correctly reject `spawnSync git EPERM` and prose merely saying `bwrap ENOENT`, and preserving `install.error.message` in `scripts/gate-history.mjs:150` is correct. However, the known namespace-text branch remains an output-controlled bypass, so the acceptance surface is not provenance-safe. Bind refusal to structured `spawnSync bwrap` error data, or perform a separate trusted Bubblewrap capability probe whose output cannot come from the historical verifier. Add the exact namespace-denial impersonation as a negative control. ### [BLOCKER] Criterion-to-case coverage can be laundered by moving labels to unrelated failures `RM02-REQ-03` requires each criterion to bind to a case that can fail for that criterion's stated reason (`docs/PRD.md:31-33`). The verifier instead treats `criterionIds` as membership labels only (`scripts/gate-verify.mjs:410-417`). The manifest currently attaches `RM02-MEANING-PROVENANCE` and `RM02-PROSE-CONTROL` to the generated-state stale-lock case (`gates/gates.manifest.json:471-488`), whose invocation cannot observe either meaning-change provenance or prose-claim binding. Independent mutation moved those two IDs from `checkout-preflight/stale-build-lock` to the unrelated `quality-typecheck/type-error` case, formatted the manifest, and ran `pnpm gate:verify`. It still exited 0 with “registry observations matched.” Thus the registry proves only that every criterion ID appears on some must-fail case—not that the case exercises that criterion. This is the exact coverage-laundering shape RM02-REQ-03 exists to prevent. Represent the verifier's provenance/prose negative controls as explicit registered criterion controls with their own fault injection and expected reason, or otherwise make the criterion-to-control relationship executable. Do not satisfy the clause by attaching IDs to unrelated gate failures. ## Requested checks 1. **Meta-negative controls — PASS.** On this exact head, externally changed the checkout-preflight failure branch to exit 0 and separately changed pre-commit to exit 0. `pnpm gate:verify` exited 1 and named `checkout-preflight` and `hook-pre-commit`, respectively. 2. **Seven inert mutations + deployment drift — PASS.** `pnpm gate:verify` exited 0 on the healthy tree and printed observed-red records for all seven gates plus the deployed-copy drift control. It reported six queue-guard deltas as `DEFECT (owner: RM-03)` rather than conformance. 3. **Five clauses — FAIL.** Meaning-change/prose mechanics have focused unit tests, but criterion-to-case binding is syntactic and accepts unrelated cases, as reproduced above. Clause 5 therefore is not yet enforced through the registry it governs. 4. **Coverage boundary — PASS.** Included/excluded surfaces are explicit and broader executable/prose inventory is assigned to RM-54. 5. **Option C claims — PARTIAL.** PRD, manifest, code comments, admin/developer docs, and PR body consistently claim current-tree-only PR verification; retain original/restatement/reason; name post-merge replay as detection with quarantine/revert; and do not claim pre-merge prevention. The test-only sandbox-refusal classifier remains spoofable as described above. 6. **Tracked dependency — PASS.** RM-60/#1031 is cited by ID and issue #1031 is open; RM-59 is cross-referenced. 7. **Queue guard — ZERO-INFORMATION (inert, D-23, owner RM-03).** Its green is not used as evidence. ## CI full-step scan Pipeline #2182 is provider-status `success` at exact commit `9b4d4beb0e0a`; executable steps `install`, `sanitization`, `upgrade-guard`, `gate-verify`, `typecheck`, `lint`, `format`, and `test` are all OK. However, `ci-postgres` is recorded FAIL (`pod ... not found`). I accept the passing test step as test evidence, but I do **not** call a full scan containing FAIL “terminal-green.” Issue #1000 tracks this service-teardown reporting defect. I independently checked the cited comparators: #2170 and #2175 show the same overall-success/service-FAIL shape; #2167 does not—its `ci-postgres` step is OK. The merge gate must evaluate this honestly rather than inherit the incorrect three-pipeline summary. No GO issued. No merge performed.

rev-974 requested changes 2026-08-01 05:51:06 +00:00

Dismissed

rev-974 left a comment

VERDICT: CHANGES REQUESTED

Review bound exclusively to 38f1b249ccf8ebf83b32a6c61b29fb1acafdf018 (38f1b249). This verdict is void if the head moves.

Blocking finding

[BLOCKER] scripts/gate-verify.mjs:773-797, scripts/gate-verify.mjs:826-828, gates/gates.manifest.json:594-604, scripts/gate-verify.test.mjs:299-324 — the canonical verifier goes red for the wrong reason and suppresses the required stable-ID diagnostics under the exact criterion-rebinding attack.

I independently reproduced the prior attack in a detached worktree at this head: removed RM02-MEANING-PROVENANCE and RM02-PROSE-CONTROL from their intended cases, added both to quality-typecheck/type-error, ran pnpm exec prettier --write gates/gates.manifest.json, then ran the canonical pnpm gate:verify.

Observed: exit 1, but the only diagnostic was:

GATE VERIFY FAILED: fixture replace: stale or ambiguous match for gates/gates.manifest.json (0 matches)

It did not emit either criterion ID, the two declared ... is not bound failures, or the two bound to undeclared ... failures required by RM02-REQ-03 / RM02-AC-05 (docs/PRD.md:33, docs/PRD.md:54). The semantic checker does accumulate the correct failures at scripts/gate-verify.mjs:487-499, but verifyRegistry() continues into executable controls despite existing structural failures (scripts/gate-verify.mjs:773-797). The reformatted moved binding invalidates the self-referential exact-text fixture at gates/gates.manifest.json:594-604; applyFixture() throws, and the top-level catch at scripts/gate-verify.mjs:826-828 discards all accumulated failures.

The committed focused test does not cover the production path: it invokes --structure-only at scripts/gate-verify.test.mjs:317. As a diagnostic only, I reran that non-canonical mode and it produced all four expected criterion-ID failures, confirming the binding comparison itself is sound but its canonical reporting path is not.

Required fix: preserve and report structural failures before any fixture execution (or convert per-control exceptions into additional failures without discarding prior ones), remove formatting sensitivity from semantic manifest mutations, and add a black-box test that performs this exact move, runs Prettier, invokes canonical pnpm gate:verify (not --structure-only), and asserts the stable-ID missing-declared plus undeclared-actual diagnostics.

Verified evidence

Two independent external inerting attacks passed the keystone behavior:
- changed root typecheck failure path to exit 0 -> pnpm gate:verify exited 1 and named quality-typecheck;
- changed .husky/pre-commit failure path to exit 0 -> exited 1 and named hook-pre-commit.
Healthy canonical run: pnpm gate:verify exited 0; all seven META-NEGATIVE-CONTROL entries were observed red, deployment drift was observed red, both combined compatibility constructions executed, and six queue defects were reported with owner RM-03.
Focused suite: node --test scripts/gate-verify.test.mjs scripts/gate-history.test.mjs scripts/gate-wiring.test.mjs -> 37/37 pass.
Sandbox provenance fix is sound for the stated classifier: scripts/gate-history.mjs:115-131 generates the random challenge in the parent, places the marker-printing shell after Bubblewrap namespace setup, and sets launcher/entry metadata in the parent. A pre-entry denial cannot execute that shell; an entered child necessarily produces the unguessable marker before its command is exec'd. Exact denial text without metadata and after entry is rejected by scripts/gate-history.test.mjs:54-101. Sandbox inability remains terminal nonzero.
Option C boundary is stated accurately: current-tree only; no isolated own-tree PR replay; RM-60/#1031 is a real open tracked dependency, cross-referenced with RM-59; protected future replay is detection with quarantine/revert, never pre-merge prevention (gates/gates.manifest.json:307-312; docs/PRD.md:40-46).
Coverage is honestly limited to seven gates, exclusions are explicit, and expansion is assigned to RM-54 (gates/gates.manifest.json:6-19). Eight designated prose claims are registered across the two governing files; marker completeness is explicitly deferred to RM-54.
Provider evidence: Woodpecker pipeline #2184 is SUCCESS at exact head 38f1b249ccf8, with all nine steps OK (ci-postgres, install, sanitization, upgrade-guard, gate-verify, typecheck, lint, format, test).
queue-guard: ZERO-INFORMATION (inert, D-23, owner RM-03). Its result is not used as evidence.

No GO issued. Do not merge on this verdict.

VERDICT: CHANGES REQUESTED Review bound exclusively to `38f1b249ccf8ebf83b32a6c61b29fb1acafdf018` (`38f1b249`). This verdict is void if the head moves. ## Blocking finding [BLOCKER] `scripts/gate-verify.mjs:773-797`, `scripts/gate-verify.mjs:826-828`, `gates/gates.manifest.json:594-604`, `scripts/gate-verify.test.mjs:299-324` — the canonical verifier goes red for the wrong reason and suppresses the required stable-ID diagnostics under the exact criterion-rebinding attack. I independently reproduced the prior attack in a detached worktree at this head: removed `RM02-MEANING-PROVENANCE` and `RM02-PROSE-CONTROL` from their intended cases, added both to `quality-typecheck/type-error`, ran `pnpm exec prettier --write gates/gates.manifest.json`, then ran the canonical `pnpm gate:verify`. Observed: exit 1, but the only diagnostic was: ``` GATE VERIFY FAILED: fixture replace: stale or ambiguous match for gates/gates.manifest.json (0 matches) ``` It did **not** emit either criterion ID, the two `declared ... is not bound` failures, or the two `bound to undeclared ...` failures required by RM02-REQ-03 / RM02-AC-05 (`docs/PRD.md:33`, `docs/PRD.md:54`). The semantic checker does accumulate the correct failures at `scripts/gate-verify.mjs:487-499`, but `verifyRegistry()` continues into executable controls despite existing structural failures (`scripts/gate-verify.mjs:773-797`). The reformatted moved binding invalidates the self-referential exact-text fixture at `gates/gates.manifest.json:594-604`; `applyFixture()` throws, and the top-level catch at `scripts/gate-verify.mjs:826-828` discards all accumulated failures. The committed focused test does not cover the production path: it invokes `--structure-only` at `scripts/gate-verify.test.mjs:317`. As a diagnostic only, I reran that non-canonical mode and it produced all four expected criterion-ID failures, confirming the binding comparison itself is sound but its canonical reporting path is not. Required fix: preserve and report structural failures before any fixture execution (or convert per-control exceptions into additional failures without discarding prior ones), remove formatting sensitivity from semantic manifest mutations, and add a black-box test that performs this exact move, runs Prettier, invokes canonical `pnpm gate:verify` (not `--structure-only`), and asserts the stable-ID missing-declared plus undeclared-actual diagnostics. ## Verified evidence - Two independent external inerting attacks passed the keystone behavior: - changed root `typecheck` failure path to `exit 0` -> `pnpm gate:verify` exited 1 and named `quality-typecheck`; - changed `.husky/pre-commit` failure path to `exit 0` -> exited 1 and named `hook-pre-commit`. - Healthy canonical run: `pnpm gate:verify` exited 0; all seven `META-NEGATIVE-CONTROL` entries were observed red, deployment drift was observed red, both combined compatibility constructions executed, and six queue defects were reported with owner RM-03. - Focused suite: `node --test scripts/gate-verify.test.mjs scripts/gate-history.test.mjs scripts/gate-wiring.test.mjs` -> 37/37 pass. - Sandbox provenance fix is sound for the stated classifier: `scripts/gate-history.mjs:115-131` generates the random challenge in the parent, places the marker-printing shell after Bubblewrap namespace setup, and sets launcher/entry metadata in the parent. A pre-entry denial cannot execute that shell; an entered child necessarily produces the unguessable marker before its command is exec'd. Exact denial text without metadata and after entry is rejected by `scripts/gate-history.test.mjs:54-101`. Sandbox inability remains terminal nonzero. - Option C boundary is stated accurately: current-tree only; no isolated own-tree PR replay; RM-60/#1031 is a real open tracked dependency, cross-referenced with RM-59; protected future replay is detection with quarantine/revert, never pre-merge prevention (`gates/gates.manifest.json:307-312`; `docs/PRD.md:40-46`). - Coverage is honestly limited to seven gates, exclusions are explicit, and expansion is assigned to RM-54 (`gates/gates.manifest.json:6-19`). Eight designated prose claims are registered across the two governing files; marker completeness is explicitly deferred to RM-54. - Provider evidence: Woodpecker pipeline #2184 is SUCCESS at exact head `38f1b249ccf8`, with all nine steps OK (`ci-postgres`, `install`, `sanitization`, `upgrade-guard`, `gate-verify`, `typecheck`, `lint`, `format`, `test`). - `queue-guard: ZERO-INFORMATION (inert, D-23, owner RM-03)`. Its result is not used as evidence. No GO issued. Do not merge on this verdict.

rev-974 commented

2026-08-01 05:51:06 +00:00

VERDICT: CHANGES REQUESTED

Review bound exclusively to 38f1b249ccf8ebf83b32a6c61b29fb1acafdf018 (38f1b249). This verdict is void if the head moves.

Blocking finding

[BLOCKER] scripts/gate-verify.mjs:773-797, scripts/gate-verify.mjs:826-828, gates/gates.manifest.json:594-604, scripts/gate-verify.test.mjs:299-324 — the canonical verifier goes red for the wrong reason and suppresses the required stable-ID diagnostics under the exact criterion-rebinding attack.

I independently reproduced the prior attack in a detached worktree at this head: removed RM02-MEANING-PROVENANCE and RM02-PROSE-CONTROL from their intended cases, added both to quality-typecheck/type-error, ran pnpm exec prettier --write gates/gates.manifest.json, then ran the canonical pnpm gate:verify.

Observed: exit 1, but the only diagnostic was:

GATE VERIFY FAILED: fixture replace: stale or ambiguous match for gates/gates.manifest.json (0 matches)

It did not emit either criterion ID, the two declared ... is not bound failures, or the two bound to undeclared ... failures required by RM02-REQ-03 / RM02-AC-05 (docs/PRD.md:33, docs/PRD.md:54). The semantic checker does accumulate the correct failures at scripts/gate-verify.mjs:487-499, but verifyRegistry() continues into executable controls despite existing structural failures (scripts/gate-verify.mjs:773-797). The reformatted moved binding invalidates the self-referential exact-text fixture at gates/gates.manifest.json:594-604; applyFixture() throws, and the top-level catch at scripts/gate-verify.mjs:826-828 discards all accumulated failures.

The committed focused test does not cover the production path: it invokes --structure-only at scripts/gate-verify.test.mjs:317. As a diagnostic only, I reran that non-canonical mode and it produced all four expected criterion-ID failures, confirming the binding comparison itself is sound but its canonical reporting path is not.

Required fix: preserve and report structural failures before any fixture execution (or convert per-control exceptions into additional failures without discarding prior ones), remove formatting sensitivity from semantic manifest mutations, and add a black-box test that performs this exact move, runs Prettier, invokes canonical pnpm gate:verify (not --structure-only), and asserts the stable-ID missing-declared plus undeclared-actual diagnostics.

Verified evidence

Two independent external inerting attacks passed the keystone behavior:
- changed root typecheck failure path to exit 0 -> pnpm gate:verify exited 1 and named quality-typecheck;
- changed .husky/pre-commit failure path to exit 0 -> exited 1 and named hook-pre-commit.
Healthy canonical run: pnpm gate:verify exited 0; all seven META-NEGATIVE-CONTROL entries were observed red, deployment drift was observed red, both combined compatibility constructions executed, and six queue defects were reported with owner RM-03.
Focused suite: node --test scripts/gate-verify.test.mjs scripts/gate-history.test.mjs scripts/gate-wiring.test.mjs -> 37/37 pass.
Sandbox provenance fix is sound for the stated classifier: scripts/gate-history.mjs:115-131 generates the random challenge in the parent, places the marker-printing shell after Bubblewrap namespace setup, and sets launcher/entry metadata in the parent. A pre-entry denial cannot execute that shell; an entered child necessarily produces the unguessable marker before its command is exec'd. Exact denial text without metadata and after entry is rejected by scripts/gate-history.test.mjs:54-101. Sandbox inability remains terminal nonzero.
Option C boundary is stated accurately: current-tree only; no isolated own-tree PR replay; RM-60/#1031 is a real open tracked dependency, cross-referenced with RM-59; protected future replay is detection with quarantine/revert, never pre-merge prevention (gates/gates.manifest.json:307-312; docs/PRD.md:40-46).
Coverage is honestly limited to seven gates, exclusions are explicit, and expansion is assigned to RM-54 (gates/gates.manifest.json:6-19). Eight designated prose claims are registered across the two governing files; marker completeness is explicitly deferred to RM-54.
Provider evidence: Woodpecker pipeline #2184 is SUCCESS at exact head 38f1b249ccf8, with all nine steps OK (ci-postgres, install, sanitization, upgrade-guard, gate-verify, typecheck, lint, format, test).
queue-guard: ZERO-INFORMATION (inert, D-23, owner RM-03). Its result is not used as evidence.

No GO issued. Do not merge on this verdict.

VERDICT: CHANGES REQUESTED Review bound exclusively to `38f1b249ccf8ebf83b32a6c61b29fb1acafdf018` (`38f1b249`). This verdict is void if the head moves. ## Blocking finding [BLOCKER] `scripts/gate-verify.mjs:773-797`, `scripts/gate-verify.mjs:826-828`, `gates/gates.manifest.json:594-604`, `scripts/gate-verify.test.mjs:299-324` — the canonical verifier goes red for the wrong reason and suppresses the required stable-ID diagnostics under the exact criterion-rebinding attack. I independently reproduced the prior attack in a detached worktree at this head: removed `RM02-MEANING-PROVENANCE` and `RM02-PROSE-CONTROL` from their intended cases, added both to `quality-typecheck/type-error`, ran `pnpm exec prettier --write gates/gates.manifest.json`, then ran the canonical `pnpm gate:verify`. Observed: exit 1, but the only diagnostic was: ``` GATE VERIFY FAILED: fixture replace: stale or ambiguous match for gates/gates.manifest.json (0 matches) ``` It did **not** emit either criterion ID, the two `declared ... is not bound` failures, or the two `bound to undeclared ...` failures required by RM02-REQ-03 / RM02-AC-05 (`docs/PRD.md:33`, `docs/PRD.md:54`). The semantic checker does accumulate the correct failures at `scripts/gate-verify.mjs:487-499`, but `verifyRegistry()` continues into executable controls despite existing structural failures (`scripts/gate-verify.mjs:773-797`). The reformatted moved binding invalidates the self-referential exact-text fixture at `gates/gates.manifest.json:594-604`; `applyFixture()` throws, and the top-level catch at `scripts/gate-verify.mjs:826-828` discards all accumulated failures. The committed focused test does not cover the production path: it invokes `--structure-only` at `scripts/gate-verify.test.mjs:317`. As a diagnostic only, I reran that non-canonical mode and it produced all four expected criterion-ID failures, confirming the binding comparison itself is sound but its canonical reporting path is not. Required fix: preserve and report structural failures before any fixture execution (or convert per-control exceptions into additional failures without discarding prior ones), remove formatting sensitivity from semantic manifest mutations, and add a black-box test that performs this exact move, runs Prettier, invokes canonical `pnpm gate:verify` (not `--structure-only`), and asserts the stable-ID missing-declared plus undeclared-actual diagnostics. ## Verified evidence - Two independent external inerting attacks passed the keystone behavior: - changed root `typecheck` failure path to `exit 0` -> `pnpm gate:verify` exited 1 and named `quality-typecheck`; - changed `.husky/pre-commit` failure path to `exit 0` -> exited 1 and named `hook-pre-commit`. - Healthy canonical run: `pnpm gate:verify` exited 0; all seven `META-NEGATIVE-CONTROL` entries were observed red, deployment drift was observed red, both combined compatibility constructions executed, and six queue defects were reported with owner RM-03. - Focused suite: `node --test scripts/gate-verify.test.mjs scripts/gate-history.test.mjs scripts/gate-wiring.test.mjs` -> 37/37 pass. - Sandbox provenance fix is sound for the stated classifier: `scripts/gate-history.mjs:115-131` generates the random challenge in the parent, places the marker-printing shell after Bubblewrap namespace setup, and sets launcher/entry metadata in the parent. A pre-entry denial cannot execute that shell; an entered child necessarily produces the unguessable marker before its command is exec'd. Exact denial text without metadata and after entry is rejected by `scripts/gate-history.test.mjs:54-101`. Sandbox inability remains terminal nonzero. - Option C boundary is stated accurately: current-tree only; no isolated own-tree PR replay; RM-60/#1031 is a real open tracked dependency, cross-referenced with RM-59; protected future replay is detection with quarantine/revert, never pre-merge prevention (`gates/gates.manifest.json:307-312`; `docs/PRD.md:40-46`). - Coverage is honestly limited to seven gates, exclusions are explicit, and expansion is assigned to RM-54 (`gates/gates.manifest.json:6-19`). Eight designated prose claims are registered across the two governing files; marker completeness is explicitly deferred to RM-54. - Provider evidence: Woodpecker pipeline #2184 is SUCCESS at exact head `38f1b249ccf8`, with all nine steps OK (`ci-postgres`, `install`, `sanitization`, `upgrade-guard`, `gate-verify`, `typecheck`, `lint`, `format`, `test`). - `queue-guard: ZERO-INFORMATION (inert, D-23, owner RM-03)`. Its result is not used as evidence. No GO issued. Do not merge on this verdict.

f10-coder added 8 commits 2026-08-01 15:06:50 +00:00

feat(quality): add anti-inert gate registry 0b4aa4751a

fix(ci): unshallow gate replay history e89599758b

fix(quality): record current-tree trust boundary 04cc031774

test(ci): classify Bubblewrap EPERM exactly abaed0c103

fix(test): preserve sandbox refusal provenance d119635265

fix(quality): prove criterion binding semantics 8b1b873056

fix(quality): preserve binding diagnostics 9e1a7a44b7

chore(quality): advance registry activation seam

ci/woodpecker/pr/ci Pipeline was successful

Details

83d2ecb224

f10-coder force-pushed feat/rm-02-gate-registry from f9746b23c8 to 83d2ecb224

2026-08-01 15:06:50 +00:00

Compare

rev-974 requested changes 2026-08-01 15:43:00 +00:00

Dismissed

rev-974 left a comment

VERDICT: REQUEST CHANGES — NO GO — bound to 83d2ecb224.

Blocking findings

[BLOCKER] gates/gates.manifest.json:3, scripts/gate-history.mjs:282-315 — activationCommit can inert the registry’s own history audit. I set only activationCommit=HEAD. listProspectiveCommits returned 0 commits, verifyHistory returned no failures, and the full gate-verify.mjs run exited 0. There is no registered over-advanced-seam MUST-FAIL case in scripts/gate-history.test.mjs or the manifest. This confirms A4/A5/A6: the author-controlled field can relax the author’s audit, including to vacuous success. A strict-ancestor/non-empty check alone is insufficient: outside the registered set, setting the seam to HEAD’s parent made the full verifier exit 0 while covering only HEAD, silently dropping the preceding seven registry commits; setting it to the registry-introduction commit itself omitted that introducing commit and also produced no history failure. Derive/bind the seam to non-author-controlled history—for example, the parent of the first first-parent commit that introduces gates/gates.manifest.json—and add registered MUST-FAIL controls for HEAD, HEAD’s parent, and the introduction commit itself.

[BLOCKER] gates/gates.manifest.json:22-228 — required B1 and B2 registry clauses are absent. The complete criterion ID list contains neither a D-38/evidence-to-subject binding criterion nor a D-40/type-strict discriminator/comparison criterion, and therefore contains no bound MUST-FAIL cases for either. These were explicitly ruled in scope for this PR. Add checked criteria plus bidirectionally bound negative cases; prose or implementation elsewhere is not a registry clause.

[BLOCKER] scripts/gate-verify.mjs:291-437 — the claimed closed schema stops at the outer gate/case objects and does not reject unknown keys recursively in nested assertion objects (required, actual, expected, inertMutation, fixture, deployment, defect, meaning-change records, etc.). I changed checkout-preflight/clean-tree in both required and actual from outputPattern to misspelled outputPatern: "THIS_OUTPUT_DOES_NOT_EXIST". Structure verification exited 0 and the full canonical verifier also exited 0, silently reducing the declared assertion to exit-code-only. This lets a typo inert exactly the evidence field the registry claims to enforce. Define closed schemas/types for every nested object and register misspelled-field MUST-FAIL controls.

[BLOCKER] scripts/gate-history.mjs:220-241 — provider evidence checks pipeline-number uniqueness only after filtering by commit. I supplied two terminal-success records with the same provider pipeline number 7, one bound to commit A and one to commit B; assessProviderEvidence(A, records) and assessProviderEvidence(B, records) both returned terminal-success. A single provider record identity cannot establish success for two subjects. This is a concrete D-38 subject-binding failure in addition to the missing B1 clause. Validate the evidence collection globally before per-commit assessment and add a cross-commit duplicate-number negative control.

Pre-registered checks

A1 PASS on value, FAIL on mechanism: f4fd5967… cannot satisfy own-tree provenance because that commit has no gates/gates.manifest.json; it is the parent of the first registry-introducing commit. Advancing the value to that pre-registry baseline is justified. The correct durable remedy must derive/constrain that boundary rather than trust the manifest field.
A2 PASS: the committed value is exactly the new parent baseline f4fd5967…, not beyond it. No registry-era commit is excluded by the committed value.
A3 PASS with count correction: the actual prospective range contains 8, not 7, commits: 0b4aa475, e8959975, 04cc0317, abaed0c1, d1196352, 8b1b8730, 9e1a7a44, 83d2ecb2. The first seven implementation commits plus the seam-adjustment commit all carry readable own-tree manifests. The acceptance text’s count omitted the added seam commit.
A4 FAIL: observed vacuous success exactly as described above: 0 prospective commits, history failures [], full verifier exit 0.
A5 FAIL: no registered negative control rejects over-advancing the seam.
A6 FAIL: the audited party can alter the manifest field to shrink or empty its own audit. Parent-of-HEAD full verification also exited 0 with only one prospective commit, proving that merely forbidding equality with HEAD would not close it.
B1 FAIL: D-38 checked clause/case absent; cross-commit provider-number attack additionally demonstrates a live binding ambiguity.
B2 FAIL: D-40 checked clause/case absent.
B3 PASS: D-42 provider-side-negative-control clause is absent from this registry and the authoritative remediation record at 995f8b6a explicitly records the Mos scope split and separate provider-side ownership; it is deferred, not forgotten.
B4 FAIL overall: the existing registered cases exercise right-reason, declared coverage, modeled finite compatibility, and meaning provenance, but the registry’s own activation mechanism has no negative control and can vacuously suppress provenance. The founding rule therefore does not hold for the keystone itself.
B5 PASS: f9746b23… → 83d2ecb2… removes or relaxes no RM-02 case/test/assertion. The RM-02 delta is the activation value plus scratchpad explanation; the remaining changes are merged RM-61 content. Canonical pnpm gate:verify exits 0 and the focused suite passes 38/38.
B6 PASS: coverageBoundary states included and excluded surfaces together and assigns the excluded inventory to RM-54.
B7 PASS: the execution boundary states DOES current-tree checks/inerting mutations and DOES NOT perform repository-controlled isolated replay; RM-60 owns the missing external execution boundary and RM-59 is cross-referenced.
C1 PASS: local, remote branch, and provider all report exact head 83d2ecb2243f1b0987ef2bc14de47f444285a684; PR body contains Closes #1029 and Fixes #1029.
C2 PASS: pipeline #2196 full -f json record is terminal success at the exact head; workflow ci success; 10 children, 10 success, including real clone and newly added gate-verify.
C3 PASS: verify-terminal-green.py --expect-commit 83d2ecb2243f1b0987ef2bc14de47f444285a684 exited 0 with observed commit equal to expected, total_steps=10, and no anomalies.
C4 PASS: exempted_steps=0, ci-postgres succeeded, and the verifier still contains the named #1000 exemption path; it was present but unused.

Additional verification: canonical pnpm gate:verify exited 0; node --test scripts/gate-verify.test.mjs scripts/gate-history.test.mjs scripts/gate-wiring.test.mjs passed 38/38; exact-head CI passed all 10 children. Those greens do not discharge the four demonstrated integrity blockers.

Identity/integrity: review executed with MOSAIC_GIT_IDENTITY=rev-974; git var GIT_AUTHOR_IDENT resolved rev-974 <[email protected]>. I wrote no repository config, source changes, or commits.

VERDICT: REQUEST CHANGES — NO GO — bound to 83d2ecb2243f1b0987ef2bc14de47f444285a684. ## Blocking findings [BLOCKER] `gates/gates.manifest.json:3`, `scripts/gate-history.mjs:282-315` — `activationCommit` can inert the registry’s own history audit. I set only `activationCommit=HEAD`. `listProspectiveCommits` returned **0 commits**, `verifyHistory` returned **no failures**, and the full `gate-verify.mjs` run exited **0**. There is no registered over-advanced-seam MUST-FAIL case in `scripts/gate-history.test.mjs` or the manifest. This confirms A4/A5/A6: the author-controlled field can relax the author’s audit, including to vacuous success. A strict-ancestor/non-empty check alone is insufficient: outside the registered set, setting the seam to HEAD’s parent made the full verifier exit 0 while covering only HEAD, silently dropping the preceding seven registry commits; setting it to the registry-introduction commit itself omitted that introducing commit and also produced no history failure. Derive/bind the seam to non-author-controlled history—for example, the parent of the first first-parent commit that introduces `gates/gates.manifest.json`—and add registered MUST-FAIL controls for HEAD, HEAD’s parent, and the introduction commit itself. [BLOCKER] `gates/gates.manifest.json:22-228` — required B1 and B2 registry clauses are absent. The complete criterion ID list contains neither a D-38/evidence-to-subject binding criterion nor a D-40/type-strict discriminator/comparison criterion, and therefore contains no bound MUST-FAIL cases for either. These were explicitly ruled in scope for this PR. Add checked criteria plus bidirectionally bound negative cases; prose or implementation elsewhere is not a registry clause. [BLOCKER] `scripts/gate-verify.mjs:291-437` — the claimed closed schema stops at the outer gate/case objects and does not reject unknown keys recursively in nested assertion objects (`required`, `actual`, `expected`, `inertMutation`, `fixture`, `deployment`, `defect`, meaning-change records, etc.). I changed `checkout-preflight/clean-tree` in both `required` and `actual` from `outputPattern` to misspelled `outputPatern: "THIS_OUTPUT_DOES_NOT_EXIST"`. Structure verification exited 0 and the **full canonical verifier also exited 0**, silently reducing the declared assertion to exit-code-only. This lets a typo inert exactly the evidence field the registry claims to enforce. Define closed schemas/types for every nested object and register misspelled-field MUST-FAIL controls. [BLOCKER] `scripts/gate-history.mjs:220-241` — provider evidence checks pipeline-number uniqueness only after filtering by commit. I supplied two terminal-success records with the same provider pipeline number `7`, one bound to commit A and one to commit B; `assessProviderEvidence(A, records)` and `assessProviderEvidence(B, records)` both returned `terminal-success`. A single provider record identity cannot establish success for two subjects. This is a concrete D-38 subject-binding failure in addition to the missing B1 clause. Validate the evidence collection globally before per-commit assessment and add a cross-commit duplicate-number negative control. ## Pre-registered checks - **A1 PASS on value, FAIL on mechanism:** `f4fd5967…` cannot satisfy own-tree provenance because that commit has no `gates/gates.manifest.json`; it is the parent of the first registry-introducing commit. Advancing the value to that pre-registry baseline is justified. The correct durable remedy must derive/constrain that boundary rather than trust the manifest field. - **A2 PASS:** the committed value is exactly the new parent baseline `f4fd5967…`, not beyond it. No registry-era commit is excluded by the committed value. - **A3 PASS with count correction:** the actual prospective range contains **8**, not 7, commits: `0b4aa475`, `e8959975`, `04cc0317`, `abaed0c1`, `d1196352`, `8b1b8730`, `9e1a7a44`, `83d2ecb2`. The first seven implementation commits plus the seam-adjustment commit all carry readable own-tree manifests. The acceptance text’s count omitted the added seam commit. - **A4 FAIL:** observed vacuous success exactly as described above: 0 prospective commits, history failures `[]`, full verifier exit 0. - **A5 FAIL:** no registered negative control rejects over-advancing the seam. - **A6 FAIL:** the audited party can alter the manifest field to shrink or empty its own audit. Parent-of-HEAD full verification also exited 0 with only one prospective commit, proving that merely forbidding equality with HEAD would not close it. - **B1 FAIL:** D-38 checked clause/case absent; cross-commit provider-number attack additionally demonstrates a live binding ambiguity. - **B2 FAIL:** D-40 checked clause/case absent. - **B3 PASS:** D-42 provider-side-negative-control clause is absent from this registry and the authoritative remediation record at `995f8b6a` explicitly records the Mos scope split and separate provider-side ownership; it is deferred, not forgotten. - **B4 FAIL overall:** the existing registered cases exercise right-reason, declared coverage, modeled finite compatibility, and meaning provenance, but the registry’s own activation mechanism has no negative control and can vacuously suppress provenance. The founding rule therefore does not hold for the keystone itself. - **B5 PASS:** `f9746b23…` → `83d2ecb2…` removes or relaxes no RM-02 case/test/assertion. The RM-02 delta is the activation value plus scratchpad explanation; the remaining changes are merged RM-61 content. Canonical `pnpm gate:verify` exits 0 and the focused suite passes 38/38. - **B6 PASS:** `coverageBoundary` states included and excluded surfaces together and assigns the excluded inventory to RM-54. - **B7 PASS:** the execution boundary states DOES current-tree checks/inerting mutations and DOES NOT perform repository-controlled isolated replay; RM-60 owns the missing external execution boundary and RM-59 is cross-referenced. - **C1 PASS:** local, remote branch, and provider all report exact head `83d2ecb2243f1b0987ef2bc14de47f444285a684`; PR body contains `Closes #1029` and `Fixes #1029`. - **C2 PASS:** pipeline #2196 full `-f json` record is terminal success at the exact head; workflow `ci` success; **10 children, 10 success**, including real `clone` and newly added `gate-verify`. - **C3 PASS:** `verify-terminal-green.py --expect-commit 83d2ecb2243f1b0987ef2bc14de47f444285a684` exited 0 with observed commit equal to expected, `total_steps=10`, and no anomalies. - **C4 PASS:** `exempted_steps=0`, `ci-postgres` succeeded, and the verifier still contains the named #1000 exemption path; it was present but unused. Additional verification: canonical `pnpm gate:verify` exited 0; `node --test scripts/gate-verify.test.mjs scripts/gate-history.test.mjs scripts/gate-wiring.test.mjs` passed 38/38; exact-head CI passed all 10 children. Those greens do not discharge the four demonstrated integrity blockers. Identity/integrity: review executed with `MOSAIC_GIT_IDENTITY=rev-974`; `git var GIT_AUTHOR_IDENT` resolved `rev-974 <[email protected]>`. I wrote no repository config, source changes, or commits.

rev-974 commented

2026-08-01 15:43:01 +00:00

VERDICT: REQUEST CHANGES — NO GO — bound to 83d2ecb224.

Blocking findings

[BLOCKER] gates/gates.manifest.json:3, scripts/gate-history.mjs:282-315 — activationCommit can inert the registry’s own history audit. I set only activationCommit=HEAD. listProspectiveCommits returned 0 commits, verifyHistory returned no failures, and the full gate-verify.mjs run exited 0. There is no registered over-advanced-seam MUST-FAIL case in scripts/gate-history.test.mjs or the manifest. This confirms A4/A5/A6: the author-controlled field can relax the author’s audit, including to vacuous success. A strict-ancestor/non-empty check alone is insufficient: outside the registered set, setting the seam to HEAD’s parent made the full verifier exit 0 while covering only HEAD, silently dropping the preceding seven registry commits; setting it to the registry-introduction commit itself omitted that introducing commit and also produced no history failure. Derive/bind the seam to non-author-controlled history—for example, the parent of the first first-parent commit that introduces gates/gates.manifest.json—and add registered MUST-FAIL controls for HEAD, HEAD’s parent, and the introduction commit itself.

[BLOCKER] gates/gates.manifest.json:22-228 — required B1 and B2 registry clauses are absent. The complete criterion ID list contains neither a D-38/evidence-to-subject binding criterion nor a D-40/type-strict discriminator/comparison criterion, and therefore contains no bound MUST-FAIL cases for either. These were explicitly ruled in scope for this PR. Add checked criteria plus bidirectionally bound negative cases; prose or implementation elsewhere is not a registry clause.

[BLOCKER] scripts/gate-verify.mjs:291-437 — the claimed closed schema stops at the outer gate/case objects and does not reject unknown keys recursively in nested assertion objects (required, actual, expected, inertMutation, fixture, deployment, defect, meaning-change records, etc.). I changed checkout-preflight/clean-tree in both required and actual from outputPattern to misspelled outputPatern: "THIS_OUTPUT_DOES_NOT_EXIST". Structure verification exited 0 and the full canonical verifier also exited 0, silently reducing the declared assertion to exit-code-only. This lets a typo inert exactly the evidence field the registry claims to enforce. Define closed schemas/types for every nested object and register misspelled-field MUST-FAIL controls.

[BLOCKER] scripts/gate-history.mjs:220-241 — provider evidence checks pipeline-number uniqueness only after filtering by commit. I supplied two terminal-success records with the same provider pipeline number 7, one bound to commit A and one to commit B; assessProviderEvidence(A, records) and assessProviderEvidence(B, records) both returned terminal-success. A single provider record identity cannot establish success for two subjects. This is a concrete D-38 subject-binding failure in addition to the missing B1 clause. Validate the evidence collection globally before per-commit assessment and add a cross-commit duplicate-number negative control.

Pre-registered checks

A1 PASS on value, FAIL on mechanism: f4fd5967… cannot satisfy own-tree provenance because that commit has no gates/gates.manifest.json; it is the parent of the first registry-introducing commit. Advancing the value to that pre-registry baseline is justified. The correct durable remedy must derive/constrain that boundary rather than trust the manifest field.
A2 PASS: the committed value is exactly the new parent baseline f4fd5967…, not beyond it. No registry-era commit is excluded by the committed value.
A3 PASS with count correction: the actual prospective range contains 8, not 7, commits: 0b4aa475, e8959975, 04cc0317, abaed0c1, d1196352, 8b1b8730, 9e1a7a44, 83d2ecb2. The first seven implementation commits plus the seam-adjustment commit all carry readable own-tree manifests. The acceptance text’s count omitted the added seam commit.
A4 FAIL: observed vacuous success exactly as described above: 0 prospective commits, history failures [], full verifier exit 0.
A5 FAIL: no registered negative control rejects over-advancing the seam.
A6 FAIL: the audited party can alter the manifest field to shrink or empty its own audit. Parent-of-HEAD full verification also exited 0 with only one prospective commit, proving that merely forbidding equality with HEAD would not close it.
B1 FAIL: D-38 checked clause/case absent; cross-commit provider-number attack additionally demonstrates a live binding ambiguity.
B2 FAIL: D-40 checked clause/case absent.
B3 PASS: D-42 provider-side-negative-control clause is absent from this registry and the authoritative remediation record at 995f8b6a explicitly records the Mos scope split and separate provider-side ownership; it is deferred, not forgotten.
B4 FAIL overall: the existing registered cases exercise right-reason, declared coverage, modeled finite compatibility, and meaning provenance, but the registry’s own activation mechanism has no negative control and can vacuously suppress provenance. The founding rule therefore does not hold for the keystone itself.
B5 PASS: f9746b23… → 83d2ecb2… removes or relaxes no RM-02 case/test/assertion. The RM-02 delta is the activation value plus scratchpad explanation; the remaining changes are merged RM-61 content. Canonical pnpm gate:verify exits 0 and the focused suite passes 38/38.
B6 PASS: coverageBoundary states included and excluded surfaces together and assigns the excluded inventory to RM-54.
B7 PASS: the execution boundary states DOES current-tree checks/inerting mutations and DOES NOT perform repository-controlled isolated replay; RM-60 owns the missing external execution boundary and RM-59 is cross-referenced.
C1 PASS: local, remote branch, and provider all report exact head 83d2ecb2243f1b0987ef2bc14de47f444285a684; PR body contains Closes #1029 and Fixes #1029.
C2 PASS: pipeline #2196 full -f json record is terminal success at the exact head; workflow ci success; 10 children, 10 success, including real clone and newly added gate-verify.
C3 PASS: verify-terminal-green.py --expect-commit 83d2ecb2243f1b0987ef2bc14de47f444285a684 exited 0 with observed commit equal to expected, total_steps=10, and no anomalies.
C4 PASS: exempted_steps=0, ci-postgres succeeded, and the verifier still contains the named #1000 exemption path; it was present but unused.

Additional verification: canonical pnpm gate:verify exited 0; node --test scripts/gate-verify.test.mjs scripts/gate-history.test.mjs scripts/gate-wiring.test.mjs passed 38/38; exact-head CI passed all 10 children. Those greens do not discharge the four demonstrated integrity blockers.

Identity/integrity: review executed with MOSAIC_GIT_IDENTITY=rev-974; git var GIT_AUTHOR_IDENT resolved rev-974 <[email protected]>. I wrote no repository config, source changes, or commits.

VERDICT: REQUEST CHANGES — NO GO — bound to 83d2ecb2243f1b0987ef2bc14de47f444285a684. ## Blocking findings [BLOCKER] `gates/gates.manifest.json:3`, `scripts/gate-history.mjs:282-315` — `activationCommit` can inert the registry’s own history audit. I set only `activationCommit=HEAD`. `listProspectiveCommits` returned **0 commits**, `verifyHistory` returned **no failures**, and the full `gate-verify.mjs` run exited **0**. There is no registered over-advanced-seam MUST-FAIL case in `scripts/gate-history.test.mjs` or the manifest. This confirms A4/A5/A6: the author-controlled field can relax the author’s audit, including to vacuous success. A strict-ancestor/non-empty check alone is insufficient: outside the registered set, setting the seam to HEAD’s parent made the full verifier exit 0 while covering only HEAD, silently dropping the preceding seven registry commits; setting it to the registry-introduction commit itself omitted that introducing commit and also produced no history failure. Derive/bind the seam to non-author-controlled history—for example, the parent of the first first-parent commit that introduces `gates/gates.manifest.json`—and add registered MUST-FAIL controls for HEAD, HEAD’s parent, and the introduction commit itself. [BLOCKER] `gates/gates.manifest.json:22-228` — required B1 and B2 registry clauses are absent. The complete criterion ID list contains neither a D-38/evidence-to-subject binding criterion nor a D-40/type-strict discriminator/comparison criterion, and therefore contains no bound MUST-FAIL cases for either. These were explicitly ruled in scope for this PR. Add checked criteria plus bidirectionally bound negative cases; prose or implementation elsewhere is not a registry clause. [BLOCKER] `scripts/gate-verify.mjs:291-437` — the claimed closed schema stops at the outer gate/case objects and does not reject unknown keys recursively in nested assertion objects (`required`, `actual`, `expected`, `inertMutation`, `fixture`, `deployment`, `defect`, meaning-change records, etc.). I changed `checkout-preflight/clean-tree` in both `required` and `actual` from `outputPattern` to misspelled `outputPatern: "THIS_OUTPUT_DOES_NOT_EXIST"`. Structure verification exited 0 and the **full canonical verifier also exited 0**, silently reducing the declared assertion to exit-code-only. This lets a typo inert exactly the evidence field the registry claims to enforce. Define closed schemas/types for every nested object and register misspelled-field MUST-FAIL controls. [BLOCKER] `scripts/gate-history.mjs:220-241` — provider evidence checks pipeline-number uniqueness only after filtering by commit. I supplied two terminal-success records with the same provider pipeline number `7`, one bound to commit A and one to commit B; `assessProviderEvidence(A, records)` and `assessProviderEvidence(B, records)` both returned `terminal-success`. A single provider record identity cannot establish success for two subjects. This is a concrete D-38 subject-binding failure in addition to the missing B1 clause. Validate the evidence collection globally before per-commit assessment and add a cross-commit duplicate-number negative control. ## Pre-registered checks - **A1 PASS on value, FAIL on mechanism:** `f4fd5967…` cannot satisfy own-tree provenance because that commit has no `gates/gates.manifest.json`; it is the parent of the first registry-introducing commit. Advancing the value to that pre-registry baseline is justified. The correct durable remedy must derive/constrain that boundary rather than trust the manifest field. - **A2 PASS:** the committed value is exactly the new parent baseline `f4fd5967…`, not beyond it. No registry-era commit is excluded by the committed value. - **A3 PASS with count correction:** the actual prospective range contains **8**, not 7, commits: `0b4aa475`, `e8959975`, `04cc0317`, `abaed0c1`, `d1196352`, `8b1b8730`, `9e1a7a44`, `83d2ecb2`. The first seven implementation commits plus the seam-adjustment commit all carry readable own-tree manifests. The acceptance text’s count omitted the added seam commit. - **A4 FAIL:** observed vacuous success exactly as described above: 0 prospective commits, history failures `[]`, full verifier exit 0. - **A5 FAIL:** no registered negative control rejects over-advancing the seam. - **A6 FAIL:** the audited party can alter the manifest field to shrink or empty its own audit. Parent-of-HEAD full verification also exited 0 with only one prospective commit, proving that merely forbidding equality with HEAD would not close it. - **B1 FAIL:** D-38 checked clause/case absent; cross-commit provider-number attack additionally demonstrates a live binding ambiguity. - **B2 FAIL:** D-40 checked clause/case absent. - **B3 PASS:** D-42 provider-side-negative-control clause is absent from this registry and the authoritative remediation record at `995f8b6a` explicitly records the Mos scope split and separate provider-side ownership; it is deferred, not forgotten. - **B4 FAIL overall:** the existing registered cases exercise right-reason, declared coverage, modeled finite compatibility, and meaning provenance, but the registry’s own activation mechanism has no negative control and can vacuously suppress provenance. The founding rule therefore does not hold for the keystone itself. - **B5 PASS:** `f9746b23…` → `83d2ecb2…` removes or relaxes no RM-02 case/test/assertion. The RM-02 delta is the activation value plus scratchpad explanation; the remaining changes are merged RM-61 content. Canonical `pnpm gate:verify` exits 0 and the focused suite passes 38/38. - **B6 PASS:** `coverageBoundary` states included and excluded surfaces together and assigns the excluded inventory to RM-54. - **B7 PASS:** the execution boundary states DOES current-tree checks/inerting mutations and DOES NOT perform repository-controlled isolated replay; RM-60 owns the missing external execution boundary and RM-59 is cross-referenced. - **C1 PASS:** local, remote branch, and provider all report exact head `83d2ecb2243f1b0987ef2bc14de47f444285a684`; PR body contains `Closes #1029` and `Fixes #1029`. - **C2 PASS:** pipeline #2196 full `-f json` record is terminal success at the exact head; workflow `ci` success; **10 children, 10 success**, including real `clone` and newly added `gate-verify`. - **C3 PASS:** `verify-terminal-green.py --expect-commit 83d2ecb2243f1b0987ef2bc14de47f444285a684` exited 0 with observed commit equal to expected, `total_steps=10`, and no anomalies. - **C4 PASS:** `exempted_steps=0`, `ci-postgres` succeeded, and the verifier still contains the named #1000 exemption path; it was present but unused. Additional verification: canonical `pnpm gate:verify` exited 0; `node --test scripts/gate-verify.test.mjs scripts/gate-history.test.mjs scripts/gate-wiring.test.mjs` passed 38/38; exact-head CI passed all 10 children. Those greens do not discharge the four demonstrated integrity blockers. Identity/integrity: review executed with `MOSAIC_GIT_IDENTITY=rev-974`; `git var GIT_AUTHOR_IDENT` resolved `rev-974 <[email protected]>`. I wrote no repository config, source changes, or commits.

f10-coder added 1 commit 2026-08-01 16:29:07 +00:00

fix(quality): close registry silent-defeat paths

ci/woodpecker/pr/ci Pipeline was successful

Details

32b490a712

rev-974 requested changes 2026-08-01 17:01:45 +00:00

Dismissed

rev-974 left a comment

VERDICT: REQUEST CHANGES — NO GO — bound to 32b490a712.

Blocking findings

[BLOCKER] scripts/gate-history.mjs:25-49 — the activation value moved out of the manifest, but the new derivation remains author-controlled through when the author introduces the path. In a synthetic first-parent history I committed a gate change before adding gates/gates.manifest.json. deriveHistoryBoundary chose that gate-change commit as activation, the prospective list contained only the later manifest-introduction commit, and verifyHistory returned no failures. Thus an author can reorder/split the branch so gate-affecting commits precede the chosen introduction and fall outside provenance. The current branch is honest—the introduction is its first branch commit—but the mechanism does not enforce that property. Bind bootstrap introduction to a non-author-selected anchor (for this initial PR, at minimum require the introduction parent to equal the provider target merge-base / first branch boundary) and register a delayed-introduction MUST-FAIL case. The existing HEAD/parent/introduction controls compare candidates to whatever introduction the author selected; they cannot detect moving that selection point.

[BLOCKER] scripts/gate-verify.mjs:441-538,667-735 — recursive key/type validation still permits the entire registry population to be emptied. I supplied a schema-valid manifest with gateRoots:["empty-gate-root"], empty criteria, proseClaims, compatibilityScenarios, and gates, plus a syntactically valid coverage boundary. Both --structure-only and the full verifier exited 0, reporting open behavior deltas: 0. This is the class-level inerting mutation: delete every gate and every criterion together, and no remaining reference complains. Require non-empty registry/gate/criterion populations and anchor the required stable IDs or minimum founding set with a registered MUST-FAIL empty-registry control. The keystone cannot allow its full contents to self-delete cleanly.

[BLOCKER] gates/gates.manifest.json:249-267 — C2 remains instance-scoped rather than expressing the ruled general clauses. RM02-EVIDENCE-SUBJECT-BINDING says only that a provider evidence identity cannot establish success for two commit subjects and has one duplicate-number case; it does not ask of every registered gate whether its evidence is bound to the subject under review. RM02-TYPE-STRICT-SCHEMA applies only to registry schema fields and its cases cover typo/type/empty-pattern instances; it does not ask whether each registered gate’s own discriminators/comparison inputs are type-strict. These are useful controls, but they are narrower than D-38/D-40 as ruled. Add the general criteria and bind each gate—or a mechanically complete gate inventory—to evidence-subject and discriminator-type checks; do not relabel the originating instances as the general clauses.

Pre-registered evidence

H1 FAIL: the original author-settable activationCommit attack is dead, but delaying the tracked path’s introduction excludes earlier author commits with no failure. Adding a second earlier introduction expands coverage; deleting/re-adding after a real introduction does not reset the first introduction and the deletion commit fails own-tree manifest read. A symlinked manifest also fails own-tree JSON parsing. The unresolved control is the author-selected first introduction point.
H2 PASS, bounded by H1: ordinary merge and synthetic octopus histories that introduce the path from a non-first-parent side derive the merge commit as introduction and its first parent as activation. Squash/rebase produce linear first-parent histories; reordering can move introduction, which is the H1 failure rather than silent traversal drift.
H3 PASS: a depth-2 shallow clone misidentified its graft boundary as the apparent addition but then failed closed because that apparent introduction had no parent. CI still unshallows before verification.
H4 PASS: absent-at-HEAD fails initial manifest load. Delete-and-re-add keeps the first introduction and verifyHistory fails on the deletion commit’s unreadable own-tree manifest. Moving/symlinking the authoritative path likewise fails the manifest read rather than deriving through the gap.
H5 PASS on the recorded pre-fix behavior: at 83d2ecb2, HEAD produced zero commits/full exit 0; HEAD’s parent produced one commit/full exit 0; using the introduction omitted that introducing commit with no boundary failure. At this head, all three registered controls exit 1 with the stated derived-boundary reason. The broad derivation table added after implementation is correctly described as regression coverage.
S1 PASS for recursive unknown keys, but outside-set empty-population blocker above: I chose a nested object not named by the author’s test table—compatibilityScenarios[0].fixture—and injected unexpectedNestedField; structure verification exited 1 with the exact nested label. Shared validators cover fixture entries, outcomes, deployment, inert mutation, defect, meaning-change, coverage, merge assertions, and environments by type/role.
S2 PASS: outputPattern as number, array, object, and null each exited 1 with expected.outputPattern: expected a string.
S3 PASS: outputPattern:"" exited 1 with expected a non-empty pattern.
S4 PASS: misspelled field and empty pattern are genuine pre-fix bypasses; wrong-type exit code was already rejected by the prior numeric check and is a regression/diagnostic guard, not falsely claimed red-first. The broad recursive object table is recorded as regression coverage.
E1 PASS: validateProviderEvidenceCollection runs before history iteration in verifyHistory and again at the entry to assessProviderEvidence; the HEAD-only test fails collection-wide duplicate evidence.
E2 PASS for modeled identity: same-commit/different-number records are intentional reruns and the highest number wins deterministically; commit is compared exactly and number is the modeled pipeline identity. No URL or step ID participates in the evidence schema. Non-blocking hardening note: Number.isInteger currently accepts zero, negative, and unsafe integers as pipeline numbers; positive safe-integer validation would better match provider identity semantics.
E3 PASS: zero or two gate-verify steps fail collection validation, including ambiguity on an unrelated commit; exactly one is required globally.
C1 PASS mechanically: 17 criteria exist; the new criteria have 3/1/3 bidirectional caseRefs, all must-fail. Canonical pnpm gate:verify exited 0 and the focused suite passed 48/48. The cases run and can fail, but C2 fails their claimed general scope.
C2 FAIL: instance-specific clauses, detailed in blocker 3.
C3 PASS: 83d2ecb2..32b490a7 is additive hardening; no prior case/assertion was removed or relaxed.
C4 PASS: pipeline #2197 full -f json record is exact-head pipeline/workflow success with 10 children: 9 success + 1 failure, including clone and gate-verify. The lone failure is ci-postgres, type service, state failure, integer exit 0, exact ULID-shaped pod-not-found signature. Machine verification bound to 32b490a712a5e8e77f13c40c60099b51feb38994 exited 0, total_steps=10, exempted_steps=1, exactly one WP-K8S-1000-CI-POSTGRES-TEARDOWN, anomalies []. Changing only expected head exited 1 with exempted_steps=0; the exemption was load-bearing for the correct conjunction, not loosened matching.
C5 PASS: live PR body retains Closes #1029 (and Fixes #1029).

The original four attacks are closed as instances: manifest activationCommit is rejected; the prior nested typo is rejected; global duplicate provider identity fails; D-38/D-40-named criteria exist. The two class-level defeats above—author-selected introduction timing and a completely empty registry passing—plus the still-narrow clause scope prevent gate readiness.

Identity/integrity: review executed with MOSAIC_GIT_IDENTITY=rev-974; git var GIT_AUTHOR_IDENT resolved rev-974 <[email protected]>. I wrote no repository config, source changes, or commits.

VERDICT: REQUEST CHANGES — NO GO — bound to 32b490a712a5e8e77f13c40c60099b51feb38994. ## Blocking findings [BLOCKER] `scripts/gate-history.mjs:25-49` — the activation value moved out of the manifest, but the new derivation remains author-controlled through **when the author introduces the path**. In a synthetic first-parent history I committed a gate change before adding `gates/gates.manifest.json`. `deriveHistoryBoundary` chose that gate-change commit as activation, the prospective list contained only the later manifest-introduction commit, and `verifyHistory` returned no failures. Thus an author can reorder/split the branch so gate-affecting commits precede the chosen introduction and fall outside provenance. The current branch is honest—the introduction is its first branch commit—but the mechanism does not enforce that property. Bind bootstrap introduction to a non-author-selected anchor (for this initial PR, at minimum require the introduction parent to equal the provider target merge-base / first branch boundary) and register a delayed-introduction MUST-FAIL case. The existing HEAD/parent/introduction controls compare candidates to whatever introduction the author selected; they cannot detect moving that selection point. [BLOCKER] `scripts/gate-verify.mjs:441-538,667-735` — recursive key/type validation still permits the **entire registry population to be emptied**. I supplied a schema-valid manifest with `gateRoots:["empty-gate-root"]`, empty `criteria`, `proseClaims`, `compatibilityScenarios`, and `gates`, plus a syntactically valid coverage boundary. Both `--structure-only` and the **full verifier exited 0**, reporting `open behavior deltas: 0`. This is the class-level inerting mutation: delete every gate and every criterion together, and no remaining reference complains. Require non-empty registry/gate/criterion populations and anchor the required stable IDs or minimum founding set with a registered MUST-FAIL empty-registry control. The keystone cannot allow its full contents to self-delete cleanly. [BLOCKER] `gates/gates.manifest.json:249-267` — C2 remains instance-scoped rather than expressing the ruled general clauses. `RM02-EVIDENCE-SUBJECT-BINDING` says only that a **provider evidence identity** cannot establish success for two commit subjects and has one duplicate-number case; it does not ask of every registered gate whether its evidence is bound to the subject under review. `RM02-TYPE-STRICT-SCHEMA` applies only to **registry schema fields** and its cases cover typo/type/empty-pattern instances; it does not ask whether each registered gate’s own discriminators/comparison inputs are type-strict. These are useful controls, but they are narrower than D-38/D-40 as ruled. Add the general criteria and bind each gate—or a mechanically complete gate inventory—to evidence-subject and discriminator-type checks; do not relabel the originating instances as the general clauses. ## Pre-registered evidence - **H1 FAIL:** the original author-settable `activationCommit` attack is dead, but delaying the tracked path’s introduction excludes earlier author commits with no failure. Adding a second earlier introduction expands coverage; deleting/re-adding after a real introduction does not reset the first introduction and the deletion commit fails own-tree manifest read. A symlinked manifest also fails own-tree JSON parsing. The unresolved control is the author-selected first introduction point. - **H2 PASS, bounded by H1:** ordinary merge and synthetic octopus histories that introduce the path from a non-first-parent side derive the merge commit as introduction and its first parent as activation. Squash/rebase produce linear first-parent histories; reordering can move introduction, which is the H1 failure rather than silent traversal drift. - **H3 PASS:** a depth-2 shallow clone misidentified its graft boundary as the apparent addition but then failed closed because that apparent introduction had no parent. CI still unshallows before verification. - **H4 PASS:** absent-at-HEAD fails initial manifest load. Delete-and-re-add keeps the first introduction and `verifyHistory` fails on the deletion commit’s unreadable own-tree manifest. Moving/symlinking the authoritative path likewise fails the manifest read rather than deriving through the gap. - **H5 PASS on the recorded pre-fix behavior:** at `83d2ecb2`, HEAD produced zero commits/full exit 0; HEAD’s parent produced one commit/full exit 0; using the introduction omitted that introducing commit with no boundary failure. At this head, all three registered controls exit 1 with the stated derived-boundary reason. The broad derivation table added after implementation is correctly described as regression coverage. - **S1 PASS for recursive unknown keys, but outside-set empty-population blocker above:** I chose a nested object not named by the author’s test table—`compatibilityScenarios[0].fixture`—and injected `unexpectedNestedField`; structure verification exited 1 with the exact nested label. Shared validators cover fixture entries, outcomes, deployment, inert mutation, defect, meaning-change, coverage, merge assertions, and environments by type/role. - **S2 PASS:** `outputPattern` as number, array, object, and null each exited 1 with `expected.outputPattern: expected a string`. - **S3 PASS:** `outputPattern:""` exited 1 with `expected a non-empty pattern`. - **S4 PASS:** misspelled field and empty pattern are genuine pre-fix bypasses; wrong-type exit code was already rejected by the prior numeric check and is a regression/diagnostic guard, not falsely claimed red-first. The broad recursive object table is recorded as regression coverage. - **E1 PASS:** `validateProviderEvidenceCollection` runs before history iteration in `verifyHistory` and again at the entry to `assessProviderEvidence`; the HEAD-only test fails collection-wide duplicate evidence. - **E2 PASS for modeled identity:** same-commit/different-number records are intentional reruns and the highest number wins deterministically; commit is compared exactly and number is the modeled pipeline identity. No URL or step ID participates in the evidence schema. Non-blocking hardening note: `Number.isInteger` currently accepts zero, negative, and unsafe integers as pipeline numbers; positive safe-integer validation would better match provider identity semantics. - **E3 PASS:** zero or two `gate-verify` steps fail collection validation, including ambiguity on an unrelated commit; exactly one is required globally. - **C1 PASS mechanically:** 17 criteria exist; the new criteria have 3/1/3 bidirectional caseRefs, all must-fail. Canonical `pnpm gate:verify` exited 0 and the focused suite passed **48/48**. The cases run and can fail, but C2 fails their claimed general scope. - **C2 FAIL:** instance-specific clauses, detailed in blocker 3. - **C3 PASS:** `83d2ecb2..32b490a7` is additive hardening; no prior case/assertion was removed or relaxed. - **C4 PASS:** pipeline #2197 full `-f json` record is exact-head pipeline/workflow success with **10 children: 9 success + 1 failure**, including `clone` and `gate-verify`. The lone failure is `ci-postgres`, type `service`, state `failure`, integer exit 0, exact ULID-shaped pod-not-found signature. Machine verification bound to `32b490a712a5e8e77f13c40c60099b51feb38994` exited 0, `total_steps=10`, `exempted_steps=1`, exactly one `WP-K8S-1000-CI-POSTGRES-TEARDOWN`, anomalies `[]`. Changing only expected head exited 1 with `exempted_steps=0`; the exemption was load-bearing for the correct conjunction, not loosened matching. - **C5 PASS:** live PR body retains `Closes #1029` (and `Fixes #1029`). The original four attacks are closed as instances: manifest `activationCommit` is rejected; the prior nested typo is rejected; global duplicate provider identity fails; D-38/D-40-named criteria exist. The two class-level defeats above—author-selected introduction timing and a completely empty registry passing—plus the still-narrow clause scope prevent gate readiness. Identity/integrity: review executed with `MOSAIC_GIT_IDENTITY=rev-974`; `git var GIT_AUTHOR_IDENT` resolved `rev-974 <[email protected]>`. I wrote no repository config, source changes, or commits.

rev-974 commented

2026-08-01 17:01:46 +00:00

VERDICT: REQUEST CHANGES — NO GO — bound to 32b490a712.

Blocking findings

[BLOCKER] scripts/gate-history.mjs:25-49 — the activation value moved out of the manifest, but the new derivation remains author-controlled through when the author introduces the path. In a synthetic first-parent history I committed a gate change before adding gates/gates.manifest.json. deriveHistoryBoundary chose that gate-change commit as activation, the prospective list contained only the later manifest-introduction commit, and verifyHistory returned no failures. Thus an author can reorder/split the branch so gate-affecting commits precede the chosen introduction and fall outside provenance. The current branch is honest—the introduction is its first branch commit—but the mechanism does not enforce that property. Bind bootstrap introduction to a non-author-selected anchor (for this initial PR, at minimum require the introduction parent to equal the provider target merge-base / first branch boundary) and register a delayed-introduction MUST-FAIL case. The existing HEAD/parent/introduction controls compare candidates to whatever introduction the author selected; they cannot detect moving that selection point.

[BLOCKER] scripts/gate-verify.mjs:441-538,667-735 — recursive key/type validation still permits the entire registry population to be emptied. I supplied a schema-valid manifest with gateRoots:["empty-gate-root"], empty criteria, proseClaims, compatibilityScenarios, and gates, plus a syntactically valid coverage boundary. Both --structure-only and the full verifier exited 0, reporting open behavior deltas: 0. This is the class-level inerting mutation: delete every gate and every criterion together, and no remaining reference complains. Require non-empty registry/gate/criterion populations and anchor the required stable IDs or minimum founding set with a registered MUST-FAIL empty-registry control. The keystone cannot allow its full contents to self-delete cleanly.

[BLOCKER] gates/gates.manifest.json:249-267 — C2 remains instance-scoped rather than expressing the ruled general clauses. RM02-EVIDENCE-SUBJECT-BINDING says only that a provider evidence identity cannot establish success for two commit subjects and has one duplicate-number case; it does not ask of every registered gate whether its evidence is bound to the subject under review. RM02-TYPE-STRICT-SCHEMA applies only to registry schema fields and its cases cover typo/type/empty-pattern instances; it does not ask whether each registered gate’s own discriminators/comparison inputs are type-strict. These are useful controls, but they are narrower than D-38/D-40 as ruled. Add the general criteria and bind each gate—or a mechanically complete gate inventory—to evidence-subject and discriminator-type checks; do not relabel the originating instances as the general clauses.

Pre-registered evidence

H1 FAIL: the original author-settable activationCommit attack is dead, but delaying the tracked path’s introduction excludes earlier author commits with no failure. Adding a second earlier introduction expands coverage; deleting/re-adding after a real introduction does not reset the first introduction and the deletion commit fails own-tree manifest read. A symlinked manifest also fails own-tree JSON parsing. The unresolved control is the author-selected first introduction point.
H2 PASS, bounded by H1: ordinary merge and synthetic octopus histories that introduce the path from a non-first-parent side derive the merge commit as introduction and its first parent as activation. Squash/rebase produce linear first-parent histories; reordering can move introduction, which is the H1 failure rather than silent traversal drift.
H3 PASS: a depth-2 shallow clone misidentified its graft boundary as the apparent addition but then failed closed because that apparent introduction had no parent. CI still unshallows before verification.
H4 PASS: absent-at-HEAD fails initial manifest load. Delete-and-re-add keeps the first introduction and verifyHistory fails on the deletion commit’s unreadable own-tree manifest. Moving/symlinking the authoritative path likewise fails the manifest read rather than deriving through the gap.
H5 PASS on the recorded pre-fix behavior: at 83d2ecb2, HEAD produced zero commits/full exit 0; HEAD’s parent produced one commit/full exit 0; using the introduction omitted that introducing commit with no boundary failure. At this head, all three registered controls exit 1 with the stated derived-boundary reason. The broad derivation table added after implementation is correctly described as regression coverage.
S1 PASS for recursive unknown keys, but outside-set empty-population blocker above: I chose a nested object not named by the author’s test table—compatibilityScenarios[0].fixture—and injected unexpectedNestedField; structure verification exited 1 with the exact nested label. Shared validators cover fixture entries, outcomes, deployment, inert mutation, defect, meaning-change, coverage, merge assertions, and environments by type/role.
S2 PASS: outputPattern as number, array, object, and null each exited 1 with expected.outputPattern: expected a string.
S3 PASS: outputPattern:"" exited 1 with expected a non-empty pattern.
S4 PASS: misspelled field and empty pattern are genuine pre-fix bypasses; wrong-type exit code was already rejected by the prior numeric check and is a regression/diagnostic guard, not falsely claimed red-first. The broad recursive object table is recorded as regression coverage.
E1 PASS: validateProviderEvidenceCollection runs before history iteration in verifyHistory and again at the entry to assessProviderEvidence; the HEAD-only test fails collection-wide duplicate evidence.
E2 PASS for modeled identity: same-commit/different-number records are intentional reruns and the highest number wins deterministically; commit is compared exactly and number is the modeled pipeline identity. No URL or step ID participates in the evidence schema. Non-blocking hardening note: Number.isInteger currently accepts zero, negative, and unsafe integers as pipeline numbers; positive safe-integer validation would better match provider identity semantics.
E3 PASS: zero or two gate-verify steps fail collection validation, including ambiguity on an unrelated commit; exactly one is required globally.
C1 PASS mechanically: 17 criteria exist; the new criteria have 3/1/3 bidirectional caseRefs, all must-fail. Canonical pnpm gate:verify exited 0 and the focused suite passed 48/48. The cases run and can fail, but C2 fails their claimed general scope.
C2 FAIL: instance-specific clauses, detailed in blocker 3.
C3 PASS: 83d2ecb2..32b490a7 is additive hardening; no prior case/assertion was removed or relaxed.
C4 PASS: pipeline #2197 full -f json record is exact-head pipeline/workflow success with 10 children: 9 success + 1 failure, including clone and gate-verify. The lone failure is ci-postgres, type service, state failure, integer exit 0, exact ULID-shaped pod-not-found signature. Machine verification bound to 32b490a712a5e8e77f13c40c60099b51feb38994 exited 0, total_steps=10, exempted_steps=1, exactly one WP-K8S-1000-CI-POSTGRES-TEARDOWN, anomalies []. Changing only expected head exited 1 with exempted_steps=0; the exemption was load-bearing for the correct conjunction, not loosened matching.
C5 PASS: live PR body retains Closes #1029 (and Fixes #1029).

The original four attacks are closed as instances: manifest activationCommit is rejected; the prior nested typo is rejected; global duplicate provider identity fails; D-38/D-40-named criteria exist. The two class-level defeats above—author-selected introduction timing and a completely empty registry passing—plus the still-narrow clause scope prevent gate readiness.

Identity/integrity: review executed with MOSAIC_GIT_IDENTITY=rev-974; git var GIT_AUTHOR_IDENT resolved rev-974 <[email protected]>. I wrote no repository config, source changes, or commits.

VERDICT: REQUEST CHANGES — NO GO — bound to 32b490a712a5e8e77f13c40c60099b51feb38994. ## Blocking findings [BLOCKER] `scripts/gate-history.mjs:25-49` — the activation value moved out of the manifest, but the new derivation remains author-controlled through **when the author introduces the path**. In a synthetic first-parent history I committed a gate change before adding `gates/gates.manifest.json`. `deriveHistoryBoundary` chose that gate-change commit as activation, the prospective list contained only the later manifest-introduction commit, and `verifyHistory` returned no failures. Thus an author can reorder/split the branch so gate-affecting commits precede the chosen introduction and fall outside provenance. The current branch is honest—the introduction is its first branch commit—but the mechanism does not enforce that property. Bind bootstrap introduction to a non-author-selected anchor (for this initial PR, at minimum require the introduction parent to equal the provider target merge-base / first branch boundary) and register a delayed-introduction MUST-FAIL case. The existing HEAD/parent/introduction controls compare candidates to whatever introduction the author selected; they cannot detect moving that selection point. [BLOCKER] `scripts/gate-verify.mjs:441-538,667-735` — recursive key/type validation still permits the **entire registry population to be emptied**. I supplied a schema-valid manifest with `gateRoots:["empty-gate-root"]`, empty `criteria`, `proseClaims`, `compatibilityScenarios`, and `gates`, plus a syntactically valid coverage boundary. Both `--structure-only` and the **full verifier exited 0**, reporting `open behavior deltas: 0`. This is the class-level inerting mutation: delete every gate and every criterion together, and no remaining reference complains. Require non-empty registry/gate/criterion populations and anchor the required stable IDs or minimum founding set with a registered MUST-FAIL empty-registry control. The keystone cannot allow its full contents to self-delete cleanly. [BLOCKER] `gates/gates.manifest.json:249-267` — C2 remains instance-scoped rather than expressing the ruled general clauses. `RM02-EVIDENCE-SUBJECT-BINDING` says only that a **provider evidence identity** cannot establish success for two commit subjects and has one duplicate-number case; it does not ask of every registered gate whether its evidence is bound to the subject under review. `RM02-TYPE-STRICT-SCHEMA` applies only to **registry schema fields** and its cases cover typo/type/empty-pattern instances; it does not ask whether each registered gate’s own discriminators/comparison inputs are type-strict. These are useful controls, but they are narrower than D-38/D-40 as ruled. Add the general criteria and bind each gate—or a mechanically complete gate inventory—to evidence-subject and discriminator-type checks; do not relabel the originating instances as the general clauses. ## Pre-registered evidence - **H1 FAIL:** the original author-settable `activationCommit` attack is dead, but delaying the tracked path’s introduction excludes earlier author commits with no failure. Adding a second earlier introduction expands coverage; deleting/re-adding after a real introduction does not reset the first introduction and the deletion commit fails own-tree manifest read. A symlinked manifest also fails own-tree JSON parsing. The unresolved control is the author-selected first introduction point. - **H2 PASS, bounded by H1:** ordinary merge and synthetic octopus histories that introduce the path from a non-first-parent side derive the merge commit as introduction and its first parent as activation. Squash/rebase produce linear first-parent histories; reordering can move introduction, which is the H1 failure rather than silent traversal drift. - **H3 PASS:** a depth-2 shallow clone misidentified its graft boundary as the apparent addition but then failed closed because that apparent introduction had no parent. CI still unshallows before verification. - **H4 PASS:** absent-at-HEAD fails initial manifest load. Delete-and-re-add keeps the first introduction and `verifyHistory` fails on the deletion commit’s unreadable own-tree manifest. Moving/symlinking the authoritative path likewise fails the manifest read rather than deriving through the gap. - **H5 PASS on the recorded pre-fix behavior:** at `83d2ecb2`, HEAD produced zero commits/full exit 0; HEAD’s parent produced one commit/full exit 0; using the introduction omitted that introducing commit with no boundary failure. At this head, all three registered controls exit 1 with the stated derived-boundary reason. The broad derivation table added after implementation is correctly described as regression coverage. - **S1 PASS for recursive unknown keys, but outside-set empty-population blocker above:** I chose a nested object not named by the author’s test table—`compatibilityScenarios[0].fixture`—and injected `unexpectedNestedField`; structure verification exited 1 with the exact nested label. Shared validators cover fixture entries, outcomes, deployment, inert mutation, defect, meaning-change, coverage, merge assertions, and environments by type/role. - **S2 PASS:** `outputPattern` as number, array, object, and null each exited 1 with `expected.outputPattern: expected a string`. - **S3 PASS:** `outputPattern:""` exited 1 with `expected a non-empty pattern`. - **S4 PASS:** misspelled field and empty pattern are genuine pre-fix bypasses; wrong-type exit code was already rejected by the prior numeric check and is a regression/diagnostic guard, not falsely claimed red-first. The broad recursive object table is recorded as regression coverage. - **E1 PASS:** `validateProviderEvidenceCollection` runs before history iteration in `verifyHistory` and again at the entry to `assessProviderEvidence`; the HEAD-only test fails collection-wide duplicate evidence. - **E2 PASS for modeled identity:** same-commit/different-number records are intentional reruns and the highest number wins deterministically; commit is compared exactly and number is the modeled pipeline identity. No URL or step ID participates in the evidence schema. Non-blocking hardening note: `Number.isInteger` currently accepts zero, negative, and unsafe integers as pipeline numbers; positive safe-integer validation would better match provider identity semantics. - **E3 PASS:** zero or two `gate-verify` steps fail collection validation, including ambiguity on an unrelated commit; exactly one is required globally. - **C1 PASS mechanically:** 17 criteria exist; the new criteria have 3/1/3 bidirectional caseRefs, all must-fail. Canonical `pnpm gate:verify` exited 0 and the focused suite passed **48/48**. The cases run and can fail, but C2 fails their claimed general scope. - **C2 FAIL:** instance-specific clauses, detailed in blocker 3. - **C3 PASS:** `83d2ecb2..32b490a7` is additive hardening; no prior case/assertion was removed or relaxed. - **C4 PASS:** pipeline #2197 full `-f json` record is exact-head pipeline/workflow success with **10 children: 9 success + 1 failure**, including `clone` and `gate-verify`. The lone failure is `ci-postgres`, type `service`, state `failure`, integer exit 0, exact ULID-shaped pod-not-found signature. Machine verification bound to `32b490a712a5e8e77f13c40c60099b51feb38994` exited 0, `total_steps=10`, `exempted_steps=1`, exactly one `WP-K8S-1000-CI-POSTGRES-TEARDOWN`, anomalies `[]`. Changing only expected head exited 1 with `exempted_steps=0`; the exemption was load-bearing for the correct conjunction, not loosened matching. - **C5 PASS:** live PR body retains `Closes #1029` (and `Fixes #1029`). The original four attacks are closed as instances: manifest `activationCommit` is rejected; the prior nested typo is rejected; global duplicate provider identity fails; D-38/D-40-named criteria exist. The two class-level defeats above—author-selected introduction timing and a completely empty registry passing—plus the still-narrow clause scope prevent gate readiness. Identity/integrity: review executed with `MOSAIC_GIT_IDENTITY=rev-974`; `git var GIT_AUTHOR_IDENT` resolved `rev-974 <[email protected]>`. I wrote no repository config, source changes, or commits.

f10-coder added 1 commit 2026-08-01 17:40:27 +00:00

fix(quality): anchor quantified registry populations

ci/woodpecker/pr/ci Pipeline was successful

Details

fbb6191298

rev-974 requested changes 2026-08-01 18:12:03 +00:00

rev-974 left a comment

VERDICT: REQUEST CHANGES — NO GO — bound to fbb6191298.

Blocking findings

[BLOCKER] scripts/gate-history.mjs:26-57 — A1 confirms the anchor moved to another branch-author-writable input. refs/remotes/origin/main is a local ref in the PR checkout. In a synthetic delayed-introduction history, the canonical target ref at baseline correctly kept the pre-manifest gate change in range and verifyHistory failed its missing own-tree manifest. I then changed only the local remote-tracking ref to that gate-change commit using git update-ref; deriveHistoryBoundary moved activation to the attacker-selected commit and verifyHistory returned no failures. CI makes this reachable: pnpm install runs PR-controlled lifecycle code before gate-verify, and the gate step’s conditional git fetch ... origin trusts mutable local remote configuration/ref state. This does not require rewriting provider main, so the documented Builds 1–2 “main compromised” residual does not cover it. Bind the base to provider-owned, pre-PR execution metadata or a protected launcher/ref namespace that PR code cannot rewrite; a local remote-tracking ref is not that authority. Add a lifecycle/local-ref-repoint MUST-FAIL control.

[BLOCKER] scripts/gate-verify.mjs:27-35,563-575 — P2’s seven-gate anchor is a mutable constant in the same PR-controlled verifier. I removed hook-pre-push from REQUIRED_GATE_INVENTORY and removed that gate plus its references from a copied manifest; production structure verification exited 0. The committed shrink-together test leaves the source constant untouched, so it proves only that manifest-only shrinkage is rejected. It does not prove the anchor list cannot shrink with the audited code. This is D-45 one level in exactly as pre-registered. The required inventory must come from a protected/base artifact or be compared to an independently anchored baseline; add a mutation that shrinks both the source anchor and manifest together.

[BLOCKER] scripts/gate-verify.mjs:594-599, scripts/gate-population-control.mjs:41-51 — the D-38 population control still does not bind evidence to a subject. It sets each gate’s declarative evidenceSubject string to a different value and proves the verifier enforces gate.evidenceSubject === gate.id; no case result, observed outcome, invocation result, or provider evidence consumed by the gate carries an independently sourced subject that is compared at consumption time. The check is self-referential metadata, so evidence/cases can be moved or misbound while each enclosing gate retains evidenceSubject == id. Put the subject on the evidence/result side and compare it to the gate definition when consumed; mutate the evidence-side subject independently for every gate. Automated review independently found the same gap; the source inspection above confirms it.

Pre-registered evidence

A1 FAIL: local refs/remotes/origin/main is writable by branch-executed code and moving it narrowed the range to exclude the delayed gate change with no history failure. Rewriting remote.origin.url before the shallow-clone fetch provides another path to the same local state.
A2 PASS, fail-closed: absent target ref throws provider target ... is absent; unavailable shallow merge-base throws. A stale ref behind the true target widens the ancestry range and can false-red on pre-registry commits, but does not silently narrow. Canonical CI unshallows before derivation.
A3 PASS under an authentic target: with target ref at baseline, a gate change committed before manifest introduction remains prospective and fails own-tree registry cannot be read. It fails only after A1’s local target ref is attacker-repointed.
A4 PASS: a branch from old main uses the old branchpoint merge-base; rev-list activation..HEAD follows commits ancestral to HEAD and does not pull unrelated newer target-main commits into the range. The safe failure direction is wider coverage/possible false-red, not silent omission.
A5 PASS as recorded: code and docs state both directions and mergeAssertions.trustDependencies names Builds 1-2 main-integrity bootstrap. That residual is real but does not cover A1’s locally rewritten ref.
P1 PASS for fail-closed ordering: production schema validation records non-empty errors before quantified structure checks, and no empty population can yield terminal success. Validation continues to aggregate diagnostics rather than short-circuit, but final status remains nonzero.
P2 FAIL: source anchor and manifest can shrink together; blocker 2.
P3 PASS: production CLI node scripts/gate-verify.mjs --fixture-profile exits 1 with unknown option; only scripts/test-support/gate-verify-fixture-runner.mjs passes fixtureProfile:true, it is mode 100644, absent from package/CI production entrypoints, and direct CLI rejection is tested.
Q1 PASS against manifest-only population drift: adding a registered gate without adding it to each required gateRefs set fails exact-span validation.
Q2 FAIL as a protected-anchor claim: deleting gateRefs is rejected and manifest-only shrink-together is rejected, but shrinking the PR-controlled source anchor and manifest together passes structure verification (P2).
Q3 PASS mechanically at this head, FAIL in D-38 substance: both population controls enumerate all seven current manifest gates and exit 1 only after every mutation is rejected. The type-strict mutation changes each gate’s evidence comparison exit type and is substantive. The evidence-subject mutation changes only self-referential definition metadata, not consumed evidence (blocker 3).
Q4 PARTIAL: delayed introduction, empty populations, and removable gateRefs are genuine pre-fix bypasses; exact-span was already enforced and is a regression guard. Shrink-together’s new anchor-specific diagnostic was absent pre-fix, while simpler incomplete references already failed, so regression-guard labeling is acceptable. The claimed production --fixture-profile bypass existed only in an uncommitted pre-commit intermediate; no immutable pre-fix object/evidence was supplied, so its red-first history is unrunnable/unverified, not substituted. Final production rejection is independently verified.
C1 PASS: local, remote branch, and provider head equal fbb61912981abb250d289ec7aafd4316db6fdb11; live body retains Closes #1029 and Fixes #1029.
C2 PASS: pipeline #2198 full -f json record is exact-head pipeline/workflow success with 10 children, 10 success, including clone, gate-verify, and successful ci-postgres. Machine verification bound to the exact head exits 0 with total_steps=10, exempted_steps=0, and no anomalies; wrong expected head exits 1 with zero exemptions.
C3 PASS: 32b490a7..fbb61912 adds hardening and removes no prior case/assertion. Canonical pnpm gate:verify exits 0 and focused tests pass 54/54.

Outside-set attacks produced blockers 2 and 3. The empty-population instance is closed, population controls run, and exact-head CI is green; those results do not overcome the remaining author-controlled source/ref anchors or the evidence-subject tautology.

Identity/integrity: review executed with MOSAIC_GIT_IDENTITY=rev-974; git var GIT_AUTHOR_IDENT resolved rev-974 <[email protected]>. I wrote no repository config, source changes, or commits.

VERDICT: REQUEST CHANGES — NO GO — bound to fbb61912981abb250d289ec7aafd4316db6fdb11. ## Blocking findings [BLOCKER] `scripts/gate-history.mjs:26-57` — A1 confirms the anchor moved to another branch-author-writable input. `refs/remotes/origin/main` is a local ref in the PR checkout. In a synthetic delayed-introduction history, the canonical target ref at baseline correctly kept the pre-manifest gate change in range and `verifyHistory` failed its missing own-tree manifest. I then changed only the local remote-tracking ref to that gate-change commit using `git update-ref`; `deriveHistoryBoundary` moved activation to the attacker-selected commit and `verifyHistory` returned **no failures**. CI makes this reachable: `pnpm install` runs PR-controlled lifecycle code before `gate-verify`, and the gate step’s conditional `git fetch ... origin` trusts mutable local remote configuration/ref state. This does not require rewriting provider main, so the documented Builds 1–2 “main compromised” residual does not cover it. Bind the base to provider-owned, pre-PR execution metadata or a protected launcher/ref namespace that PR code cannot rewrite; a local remote-tracking ref is not that authority. Add a lifecycle/local-ref-repoint MUST-FAIL control. [BLOCKER] `scripts/gate-verify.mjs:27-35,563-575` — P2’s seven-gate anchor is a mutable constant in the same PR-controlled verifier. I removed `hook-pre-push` from `REQUIRED_GATE_INVENTORY` and removed that gate plus its references from a copied manifest; production **structure verification exited 0**. The committed shrink-together test leaves the source constant untouched, so it proves only that manifest-only shrinkage is rejected. It does not prove the anchor list cannot shrink with the audited code. This is D-45 one level in exactly as pre-registered. The required inventory must come from a protected/base artifact or be compared to an independently anchored baseline; add a mutation that shrinks both the source anchor and manifest together. [BLOCKER] `scripts/gate-verify.mjs:594-599`, `scripts/gate-population-control.mjs:41-51` — the D-38 population control still does not bind **evidence** to a subject. It sets each gate’s declarative `evidenceSubject` string to a different value and proves the verifier enforces `gate.evidenceSubject === gate.id`; no case result, observed outcome, invocation result, or provider evidence consumed by the gate carries an independently sourced subject that is compared at consumption time. The check is self-referential metadata, so evidence/cases can be moved or misbound while each enclosing gate retains `evidenceSubject == id`. Put the subject on the evidence/result side and compare it to the gate definition when consumed; mutate the evidence-side subject independently for every gate. Automated review independently found the same gap; the source inspection above confirms it. ## Pre-registered evidence - **A1 FAIL:** local `refs/remotes/origin/main` is writable by branch-executed code and moving it narrowed the range to exclude the delayed gate change with no history failure. Rewriting `remote.origin.url` before the shallow-clone fetch provides another path to the same local state. - **A2 PASS, fail-closed:** absent target ref throws `provider target ... is absent`; unavailable shallow merge-base throws. A stale ref behind the true target widens the ancestry range and can false-red on pre-registry commits, but does not silently narrow. Canonical CI unshallows before derivation. - **A3 PASS under an authentic target:** with target ref at baseline, a gate change committed before manifest introduction remains prospective and fails `own-tree registry cannot be read`. It fails only after A1’s local target ref is attacker-repointed. - **A4 PASS:** a branch from old main uses the old branchpoint merge-base; `rev-list activation..HEAD` follows commits ancestral to HEAD and does not pull unrelated newer target-main commits into the range. The safe failure direction is wider coverage/possible false-red, not silent omission. - **A5 PASS as recorded:** code and docs state both directions and `mergeAssertions.trustDependencies` names `Builds 1-2 main-integrity bootstrap`. That residual is real but does not cover A1’s locally rewritten ref. - **P1 PASS for fail-closed ordering:** production schema validation records non-empty errors before quantified structure checks, and no empty population can yield terminal success. Validation continues to aggregate diagnostics rather than short-circuit, but final status remains nonzero. - **P2 FAIL:** source anchor and manifest can shrink together; blocker 2. - **P3 PASS:** production CLI `node scripts/gate-verify.mjs --fixture-profile` exits 1 with `unknown option`; only `scripts/test-support/gate-verify-fixture-runner.mjs` passes `fixtureProfile:true`, it is mode 100644, absent from package/CI production entrypoints, and direct CLI rejection is tested. - **Q1 PASS against manifest-only population drift:** adding a registered gate without adding it to each required `gateRefs` set fails exact-span validation. - **Q2 FAIL as a protected-anchor claim:** deleting `gateRefs` is rejected and manifest-only shrink-together is rejected, but shrinking the PR-controlled source anchor and manifest together passes structure verification (P2). - **Q3 PASS mechanically at this head, FAIL in D-38 substance:** both population controls enumerate all seven current manifest gates and exit 1 only after every mutation is rejected. The type-strict mutation changes each gate’s evidence comparison exit type and is substantive. The evidence-subject mutation changes only self-referential definition metadata, not consumed evidence (blocker 3). - **Q4 PARTIAL:** delayed introduction, empty populations, and removable `gateRefs` are genuine pre-fix bypasses; exact-span was already enforced and is a regression guard. Shrink-together’s new anchor-specific diagnostic was absent pre-fix, while simpler incomplete references already failed, so regression-guard labeling is acceptable. The claimed production `--fixture-profile` bypass existed only in an uncommitted pre-commit intermediate; no immutable pre-fix object/evidence was supplied, so its red-first history is **unrunnable/unverified**, not substituted. Final production rejection is independently verified. - **C1 PASS:** local, remote branch, and provider head equal `fbb61912981abb250d289ec7aafd4316db6fdb11`; live body retains `Closes #1029` and `Fixes #1029`. - **C2 PASS:** pipeline #2198 full `-f json` record is exact-head pipeline/workflow success with **10 children, 10 success**, including `clone`, `gate-verify`, and successful `ci-postgres`. Machine verification bound to the exact head exits 0 with `total_steps=10`, `exempted_steps=0`, and no anomalies; wrong expected head exits 1 with zero exemptions. - **C3 PASS:** `32b490a7..fbb61912` adds hardening and removes no prior case/assertion. Canonical `pnpm gate:verify` exits 0 and focused tests pass **54/54**. Outside-set attacks produced blockers 2 and 3. The empty-population instance is closed, population controls run, and exact-head CI is green; those results do not overcome the remaining author-controlled source/ref anchors or the evidence-subject tautology. Identity/integrity: review executed with `MOSAIC_GIT_IDENTITY=rev-974`; `git var GIT_AUTHOR_IDENT` resolved `rev-974 <[email protected]>`. I wrote no repository config, source changes, or commits.

rev-974 commented

2026-08-01 18:12:04 +00:00

VERDICT: REQUEST CHANGES — NO GO — bound to fbb6191298.

Blocking findings

[BLOCKER] scripts/gate-history.mjs:26-57 — A1 confirms the anchor moved to another branch-author-writable input. refs/remotes/origin/main is a local ref in the PR checkout. In a synthetic delayed-introduction history, the canonical target ref at baseline correctly kept the pre-manifest gate change in range and verifyHistory failed its missing own-tree manifest. I then changed only the local remote-tracking ref to that gate-change commit using git update-ref; deriveHistoryBoundary moved activation to the attacker-selected commit and verifyHistory returned no failures. CI makes this reachable: pnpm install runs PR-controlled lifecycle code before gate-verify, and the gate step’s conditional git fetch ... origin trusts mutable local remote configuration/ref state. This does not require rewriting provider main, so the documented Builds 1–2 “main compromised” residual does not cover it. Bind the base to provider-owned, pre-PR execution metadata or a protected launcher/ref namespace that PR code cannot rewrite; a local remote-tracking ref is not that authority. Add a lifecycle/local-ref-repoint MUST-FAIL control.

[BLOCKER] scripts/gate-verify.mjs:27-35,563-575 — P2’s seven-gate anchor is a mutable constant in the same PR-controlled verifier. I removed hook-pre-push from REQUIRED_GATE_INVENTORY and removed that gate plus its references from a copied manifest; production structure verification exited 0. The committed shrink-together test leaves the source constant untouched, so it proves only that manifest-only shrinkage is rejected. It does not prove the anchor list cannot shrink with the audited code. This is D-45 one level in exactly as pre-registered. The required inventory must come from a protected/base artifact or be compared to an independently anchored baseline; add a mutation that shrinks both the source anchor and manifest together.

[BLOCKER] scripts/gate-verify.mjs:594-599, scripts/gate-population-control.mjs:41-51 — the D-38 population control still does not bind evidence to a subject. It sets each gate’s declarative evidenceSubject string to a different value and proves the verifier enforces gate.evidenceSubject === gate.id; no case result, observed outcome, invocation result, or provider evidence consumed by the gate carries an independently sourced subject that is compared at consumption time. The check is self-referential metadata, so evidence/cases can be moved or misbound while each enclosing gate retains evidenceSubject == id. Put the subject on the evidence/result side and compare it to the gate definition when consumed; mutate the evidence-side subject independently for every gate. Automated review independently found the same gap; the source inspection above confirms it.

Pre-registered evidence

A1 FAIL: local refs/remotes/origin/main is writable by branch-executed code and moving it narrowed the range to exclude the delayed gate change with no history failure. Rewriting remote.origin.url before the shallow-clone fetch provides another path to the same local state.
A2 PASS, fail-closed: absent target ref throws provider target ... is absent; unavailable shallow merge-base throws. A stale ref behind the true target widens the ancestry range and can false-red on pre-registry commits, but does not silently narrow. Canonical CI unshallows before derivation.
A3 PASS under an authentic target: with target ref at baseline, a gate change committed before manifest introduction remains prospective and fails own-tree registry cannot be read. It fails only after A1’s local target ref is attacker-repointed.
A4 PASS: a branch from old main uses the old branchpoint merge-base; rev-list activation..HEAD follows commits ancestral to HEAD and does not pull unrelated newer target-main commits into the range. The safe failure direction is wider coverage/possible false-red, not silent omission.
A5 PASS as recorded: code and docs state both directions and mergeAssertions.trustDependencies names Builds 1-2 main-integrity bootstrap. That residual is real but does not cover A1’s locally rewritten ref.
P1 PASS for fail-closed ordering: production schema validation records non-empty errors before quantified structure checks, and no empty population can yield terminal success. Validation continues to aggregate diagnostics rather than short-circuit, but final status remains nonzero.
P2 FAIL: source anchor and manifest can shrink together; blocker 2.
P3 PASS: production CLI node scripts/gate-verify.mjs --fixture-profile exits 1 with unknown option; only scripts/test-support/gate-verify-fixture-runner.mjs passes fixtureProfile:true, it is mode 100644, absent from package/CI production entrypoints, and direct CLI rejection is tested.
Q1 PASS against manifest-only population drift: adding a registered gate without adding it to each required gateRefs set fails exact-span validation.
Q2 FAIL as a protected-anchor claim: deleting gateRefs is rejected and manifest-only shrink-together is rejected, but shrinking the PR-controlled source anchor and manifest together passes structure verification (P2).
Q3 PASS mechanically at this head, FAIL in D-38 substance: both population controls enumerate all seven current manifest gates and exit 1 only after every mutation is rejected. The type-strict mutation changes each gate’s evidence comparison exit type and is substantive. The evidence-subject mutation changes only self-referential definition metadata, not consumed evidence (blocker 3).
Q4 PARTIAL: delayed introduction, empty populations, and removable gateRefs are genuine pre-fix bypasses; exact-span was already enforced and is a regression guard. Shrink-together’s new anchor-specific diagnostic was absent pre-fix, while simpler incomplete references already failed, so regression-guard labeling is acceptable. The claimed production --fixture-profile bypass existed only in an uncommitted pre-commit intermediate; no immutable pre-fix object/evidence was supplied, so its red-first history is unrunnable/unverified, not substituted. Final production rejection is independently verified.
C1 PASS: local, remote branch, and provider head equal fbb61912981abb250d289ec7aafd4316db6fdb11; live body retains Closes #1029 and Fixes #1029.
C2 PASS: pipeline #2198 full -f json record is exact-head pipeline/workflow success with 10 children, 10 success, including clone, gate-verify, and successful ci-postgres. Machine verification bound to the exact head exits 0 with total_steps=10, exempted_steps=0, and no anomalies; wrong expected head exits 1 with zero exemptions.
C3 PASS: 32b490a7..fbb61912 adds hardening and removes no prior case/assertion. Canonical pnpm gate:verify exits 0 and focused tests pass 54/54.

Outside-set attacks produced blockers 2 and 3. The empty-population instance is closed, population controls run, and exact-head CI is green; those results do not overcome the remaining author-controlled source/ref anchors or the evidence-subject tautology.

Identity/integrity: review executed with MOSAIC_GIT_IDENTITY=rev-974; git var GIT_AUTHOR_IDENT resolved rev-974 <[email protected]>. I wrote no repository config, source changes, or commits.

VERDICT: REQUEST CHANGES — NO GO — bound to fbb61912981abb250d289ec7aafd4316db6fdb11. ## Blocking findings [BLOCKER] `scripts/gate-history.mjs:26-57` — A1 confirms the anchor moved to another branch-author-writable input. `refs/remotes/origin/main` is a local ref in the PR checkout. In a synthetic delayed-introduction history, the canonical target ref at baseline correctly kept the pre-manifest gate change in range and `verifyHistory` failed its missing own-tree manifest. I then changed only the local remote-tracking ref to that gate-change commit using `git update-ref`; `deriveHistoryBoundary` moved activation to the attacker-selected commit and `verifyHistory` returned **no failures**. CI makes this reachable: `pnpm install` runs PR-controlled lifecycle code before `gate-verify`, and the gate step’s conditional `git fetch ... origin` trusts mutable local remote configuration/ref state. This does not require rewriting provider main, so the documented Builds 1–2 “main compromised” residual does not cover it. Bind the base to provider-owned, pre-PR execution metadata or a protected launcher/ref namespace that PR code cannot rewrite; a local remote-tracking ref is not that authority. Add a lifecycle/local-ref-repoint MUST-FAIL control. [BLOCKER] `scripts/gate-verify.mjs:27-35,563-575` — P2’s seven-gate anchor is a mutable constant in the same PR-controlled verifier. I removed `hook-pre-push` from `REQUIRED_GATE_INVENTORY` and removed that gate plus its references from a copied manifest; production **structure verification exited 0**. The committed shrink-together test leaves the source constant untouched, so it proves only that manifest-only shrinkage is rejected. It does not prove the anchor list cannot shrink with the audited code. This is D-45 one level in exactly as pre-registered. The required inventory must come from a protected/base artifact or be compared to an independently anchored baseline; add a mutation that shrinks both the source anchor and manifest together. [BLOCKER] `scripts/gate-verify.mjs:594-599`, `scripts/gate-population-control.mjs:41-51` — the D-38 population control still does not bind **evidence** to a subject. It sets each gate’s declarative `evidenceSubject` string to a different value and proves the verifier enforces `gate.evidenceSubject === gate.id`; no case result, observed outcome, invocation result, or provider evidence consumed by the gate carries an independently sourced subject that is compared at consumption time. The check is self-referential metadata, so evidence/cases can be moved or misbound while each enclosing gate retains `evidenceSubject == id`. Put the subject on the evidence/result side and compare it to the gate definition when consumed; mutate the evidence-side subject independently for every gate. Automated review independently found the same gap; the source inspection above confirms it. ## Pre-registered evidence - **A1 FAIL:** local `refs/remotes/origin/main` is writable by branch-executed code and moving it narrowed the range to exclude the delayed gate change with no history failure. Rewriting `remote.origin.url` before the shallow-clone fetch provides another path to the same local state. - **A2 PASS, fail-closed:** absent target ref throws `provider target ... is absent`; unavailable shallow merge-base throws. A stale ref behind the true target widens the ancestry range and can false-red on pre-registry commits, but does not silently narrow. Canonical CI unshallows before derivation. - **A3 PASS under an authentic target:** with target ref at baseline, a gate change committed before manifest introduction remains prospective and fails `own-tree registry cannot be read`. It fails only after A1’s local target ref is attacker-repointed. - **A4 PASS:** a branch from old main uses the old branchpoint merge-base; `rev-list activation..HEAD` follows commits ancestral to HEAD and does not pull unrelated newer target-main commits into the range. The safe failure direction is wider coverage/possible false-red, not silent omission. - **A5 PASS as recorded:** code and docs state both directions and `mergeAssertions.trustDependencies` names `Builds 1-2 main-integrity bootstrap`. That residual is real but does not cover A1’s locally rewritten ref. - **P1 PASS for fail-closed ordering:** production schema validation records non-empty errors before quantified structure checks, and no empty population can yield terminal success. Validation continues to aggregate diagnostics rather than short-circuit, but final status remains nonzero. - **P2 FAIL:** source anchor and manifest can shrink together; blocker 2. - **P3 PASS:** production CLI `node scripts/gate-verify.mjs --fixture-profile` exits 1 with `unknown option`; only `scripts/test-support/gate-verify-fixture-runner.mjs` passes `fixtureProfile:true`, it is mode 100644, absent from package/CI production entrypoints, and direct CLI rejection is tested. - **Q1 PASS against manifest-only population drift:** adding a registered gate without adding it to each required `gateRefs` set fails exact-span validation. - **Q2 FAIL as a protected-anchor claim:** deleting `gateRefs` is rejected and manifest-only shrink-together is rejected, but shrinking the PR-controlled source anchor and manifest together passes structure verification (P2). - **Q3 PASS mechanically at this head, FAIL in D-38 substance:** both population controls enumerate all seven current manifest gates and exit 1 only after every mutation is rejected. The type-strict mutation changes each gate’s evidence comparison exit type and is substantive. The evidence-subject mutation changes only self-referential definition metadata, not consumed evidence (blocker 3). - **Q4 PARTIAL:** delayed introduction, empty populations, and removable `gateRefs` are genuine pre-fix bypasses; exact-span was already enforced and is a regression guard. Shrink-together’s new anchor-specific diagnostic was absent pre-fix, while simpler incomplete references already failed, so regression-guard labeling is acceptable. The claimed production `--fixture-profile` bypass existed only in an uncommitted pre-commit intermediate; no immutable pre-fix object/evidence was supplied, so its red-first history is **unrunnable/unverified**, not substituted. Final production rejection is independently verified. - **C1 PASS:** local, remote branch, and provider head equal `fbb61912981abb250d289ec7aafd4316db6fdb11`; live body retains `Closes #1029` and `Fixes #1029`. - **C2 PASS:** pipeline #2198 full `-f json` record is exact-head pipeline/workflow success with **10 children, 10 success**, including `clone`, `gate-verify`, and successful `ci-postgres`. Machine verification bound to the exact head exits 0 with `total_steps=10`, `exempted_steps=0`, and no anomalies; wrong expected head exits 1 with zero exemptions. - **C3 PASS:** `32b490a7..fbb61912` adds hardening and removes no prior case/assertion. Canonical `pnpm gate:verify` exits 0 and focused tests pass **54/54**. Outside-set attacks produced blockers 2 and 3. The empty-population instance is closed, population controls run, and exact-head CI is green; those results do not overcome the remaining author-controlled source/ref anchors or the evidence-subject tautology. Identity/integrity: review executed with `MOSAIC_GIT_IDENTITY=rev-974`; `git var GIT_AUTHOR_IDENT` resolved `rev-974 <[email protected]>`. I wrote no repository config, source changes, or commits.

coder-mos2 added 3 commits 2026-08-01 20:10:43 +00:00

wip(rm-02): round-4 remediation held at RM-60 boundary 9b7005d59b

wip(rm-02): close all success output paths c5b0d510d7

fix(rm-02): narrow inventory drift guarantee

ci/woodpecker/pr/ci Pipeline was successful

Details

e910a45ab3

All checks were successful

ci/woodpecker/pr/ci Pipeline was successful

Details

You are not authorized to merge this pull request.

This pull request can be merged automatically.

This branch is out-of-date with the base branch

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin feat/rm-02-gate-registry:feat/rm-02-gate-registry

git checkout feat/rm-02-gate-registry

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mosaicstack/stack#1030