Work order cobalt — the complete external review record

gate_b8_ac65_78_advisory_review

2026-02-02T18:07Z · gate round · gate round 1 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; advisory only):
- AC-75 is framed as independently re-confirmed after §B12, but the cited post-fix witness proves only the full-reconcile phantom branch. WO §B8 AC-75 requires the complete sequence: delta upsert, watermark advance, and phantom eviction (`the work-order close bar`). The original `evidence/wo-log-114.log` captures all three against the pre-§B12 binary. The replacement `evidence/b12-witness-008.log` captures complete-snapshot eviction and incomplete-snapshot preservation, but does not stage a delta upsert or prove watermark advance. This matters because the audit itself records that §B12 AC-115 changed sync worker claim participation and watermark handling on the delta loop (`evidence/b8-audit-001.md`, §B12 re-delivery impact). Keep the AC-75 scope honest: the phantom-evict subclaim is re-confirmed; the post-fix delta-upsert/watermark subclaims still need a post-fix witness or an explicit carry-forward argument narrow enough to survive review.
- The approach does not present one frozen final evidence manifest. The packet tells the reviewer to use `evidence/b8-note-013.md`, but that index still marks AC-67 as schema-validity asserted, AC-75 as pending §B12 re-witness, and AC-78 namespace isolation as asserted. Later artifacts materially supersede those rows: `evidence/b8-witness-001.md`, `evidence/b8-witness-004.md`, and `evidence/b12-witness-008.log`. The amended trinity audit then layers conclusions on top. A reviewer should not have to reconcile a stale index, appended audit history, and packet bullet overrides. Freeze a final per-AC manifest that points directly to the current raw witness for each sub-bar and marks superseded evidence as historical.
- AC-71 still mixes a runtime outcome with a structural substitute for a named runtime observation. WO §B8 AC-71 requires `Rejected{business_reject}` plus no invalid write fired, witnessed as cache unchanged (`the work-order close bar`). `evidence/wo-record-053.json` proves the rejection outcome, while the regenerated index closes "no PUT fired" by source-path reasoning. That reasoning is useful design proof, but the packet's own adversarial rule says not to accept assertion in place of witness. Capture a small external before/after cache check and source-side PUT journal delta around the rejected call, using the same style as the AC-69 source-journal supplement.

ALTERNATIVE FRAMING:
- Treat the handoff as a compact closure bundle, not a narrative accumulation. Build one immutable final matrix keyed by AC-65..78 and, where needed, by sub-bar. Point each cell at the latest raw external artifact, identify historical artifacts as superseded, and keep source-code arguments as complementary rationale.
- Split AC-75 explicitly into `delta upsert + watermark advance` and `complete-snapshot phantom eviction`. Carry the post-§B12 eviction witness for the second half and run the existing delta probe against the fixed binary for the first half. Keep the separate AC-115 concurrency deliverable separate without using that separation to overstate AC-75 coverage.
- Add the AC-71 external no-write observation as a cheap consistency supplement. That gives the §B8 bundle a uniform standard: deployed-runtime observations for the named behaviors, structural inspection only as corroboration.

DONE=GATE-B8-AC65-78-ADVISORY-REVIEW-20260202

gate_b8_ac65_78_regate_advisory_review

2026-02-02T18:47Z · gate round · gate round 2 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; advisory only):
- AC-75 is still overstated as a post-§B12 `delta upsert + watermark advance` witness. WO §B8 AC-75 requires a source change to be upserted by `list_changed`, followed by watermark advance and phantom eviction (`the work-order close bar`, `:3292`). In `evidence/b8-log-043.log:79-92`, the profile is loaded with the entity already present and the transcript explicitly attributes W-1 to the startup `full_reconcile`; W-2 then observes the watermark during the delta phase. The summary later relabels W-1 as `list_changed → entity upsert` (`:193-202`), but the staged sequence did not witness that path. The post-fix evidence supports full-reconcile upsert, delta watermark advance, and phantom eviction; it does not directly support delta-path upsert.
- AC-78’s frozen row omits a load-bearing sub-bar from the WO. WO §B8 AC-78 requires the bootstrap onboarding flow to run successfully for stocktrace seed-mode and partline a v3 machine-readable source spec before the runtime coexistence checks (`the work-order close bar`). The frozen matrix compresses the row to manifests, union, namespace isolation, and cross-source independence (`evidence/b8-manifest-001.md:28`). Its cited supplemental starts with profiles already on disk and loaded, then witnesses sub-bars (b)-(f) (`evidence/b8-log-021.log:10-60`); it does not witness sub-bar (a). Runtime coexistence is important, but it is not a substitute for the product claim that onboarding both source shapes succeeds.
- AC-70 remains closed by an runtime outcome plus source inspection where the WO names an external cache observation. WO §B8 AC-70 requires a passing MUTATE to return `Committed` and a `cachectl` cache update (`the work-order close bar`). The frozen row cites only `evidence/wo-record-052.json` plus complementary `the write-governance module` reasoning (`evidence/b8-manifest-001.md:20`). The earlier audit explicitly records that `cache wo-log-160.log` is stale and recommends a fresh post-commit cache store read (`evidence/b8-audit-001.md`, AC-70 note). The committed response proves a bracket result; it is not the WO-named independent cache-state witness.

ALTERNATIVE FRAMING:
- Preserve the frozen-manifest idea, but make it a sub-bar matrix instead of one compressed row per AC. Point each sub-bar directly to a raw transcript or JSON artifact; use summary markdown only as an index. Add checksums if “immutable” is intended literally.
- For AC-75, distinguish `full_reconcile upsert`, `list_changed delta upsert`, `watermark advance`, and `complete-snapshot phantom eviction`. The current evidence supports three of those four. A delta-path demonstration stages the entity only after initial reconcile and watermark initialization, then observes insertion on a later `sync_delta_start`.
- For AC-78 and AC-70, link the missing product-level observations explicitly: the two onboarding runs for AC-78(a), and a post-commit cache store read for AC-70. Keep source-code arguments as corroboration, consistent with the manifest’s stated evidence policy.

DONE=GATE-B8-AC65-78-REGATE-ADVISORY-REVIEW-20260202

gate_b8_final_advisory_review

2026-02-02T19:36Z · gate round · gate round 3 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; advisory only):
- AC-78(a) is still framed more broadly than the raw witness supports. WO §B8 AC-78 requires the bootstrap onboarding flow to run for stocktrace seed-mode and partline a v3 machine-readable source spec, with both sources then living in one sync runtime (`the work-order close bar`). The new raw artifact runs catalog builder **Pass-A only** into temporary `_ob_*wo-note-039.yaml` files (`evidence/b8-log-032.log:8-34`) and then points to a separate earlier steady-state runtime witness (`:36-41`). The supplement explicitly says full bootstrap was avoided because it would re-author tools and restart runtime (`evidence/b8-note-015.md:15-24`). That is an honest limitation, but it means the evidence composes two endpoints rather than proving the named bootstrap-to-loaded-runtime product path.
- The frozen manifest’s AC-78(a) cell violates its own “direct raw transcript/JSON” rule. The manifest says each sub-bar points directly at raw evidence, but AC-78(a) points at the summary `b8-note-015.md`, whose shorthand says “bootstrap onboard” (`evidence/b8-manifest-001.md:1-6`, `:37`). The direct transcript says Pass-A ingest only. Point the cell at `b8-log-032.log` and label the narrower observation accurately. Summary markdown should not upgrade the scope of the raw transcript.
- The closure bundle claims reproducibility artifacts that are not present under the cited paths. `b8-note-015.md` names `evidence/scripts/b8-witness-020.sh`, `b8-witness-021.sh`, and `b8-witness-022.sh`, but this workspace has no `evidence/scripts/` directory. The captured logs remain readable, so this is not a reason to discard their observations; it is a packaging weakness for an evidence bundle described as frozen and authoritative. Either include the harnesses or remove the dead references and state that only transcripts were retained.

ALTERNATIVE FRAMING:
- Keep AC-70 and AC-75 as the model: one named sub-bar, one direct raw external transcript, one narrowly stated observation. Their round-two witnesses now match the WO-level claims.
- For AC-78, separate `Pass-A shape ingestion` from `bootstrap onboard → generated artifacts → load into disposable runtime → union/ns-isolation/cross-source operations`. Run the full bootstrap path in an isolated staging runtime so production custom handlers are not at risk. If that end-to-end exercise is intentionally deferred, describe the current evidence as compositional coverage rather than a witnessed bootstrap flow.
- Make the frozen matrix mechanically auditable: direct raw paths only, explicit carry-forward labels for older witnesses, and retained harnesses or checksums where reproducibility is part of the closure claim.

DONE=GATE-B8-FINAL-ADVISORY-REVIEW-20260202

gate_b8_round4_ac65_78_advisory_review

2026-02-02T21:42Z · gate round · gate round 4 · verdict: reconsider-approach

BOTTOM-LINE: reconsider-approach

HOLES (strongest objections to the APPROACH; max 3, highest severity first; advisory only):
- AC-78(a)'s canonical bootstrap has a false-success terminal, so “loadability parse check on demand” is too narrow. The product claim is that bootstrap onboards both source shapes successfully (`the work-order close bar`). In both staged runs, Step 4 cannot find the catalog builder, logs `Skipping catalog builder ingest — Pass-A deferred`, continues, and later prints `Source Onboarding COMPLETE` with exit 0 (`evidence/b8-log-030.log:51-77,147-173`). Step 5 also says `runtime restarted and healthy — new tools loaded`, while the emitted next step is still `Activate this profile — update CORE_PROFILE_PATHS` (`:67-85,163-181`). That terminal means “files authored and an existing runtime restarted,” not “source onboarded.” The generated read-only partline artifact shows why validation is load-bearing: input `write_path: none` and the log's `no MUTATE tool authored` still produce `operations.write_entity: PUT /parts/{id}` (`the-staging-area`; `evidence/b8-log-030.log:153-155`; `the-staging-area`). Define distinct terminals: `AuthoredIncomplete` when ingest/activation is deferred, and `Onboarded` only after required ingest, profile parse, semantic validation, activation, and loaded-tool verification succeed.
- The AC-78 evidence still composes independent halves instead of exercising the load-bearing product path. The addendum is honest: lane-1 catalog builder manifests and bootstrap-authored profiles/tools ran independently, and bootstrap never consumed the `_ob_*wo-note-039.yaml` outputs (`evidence/b8-log-030.log:245-264`). The coexistence witness then proves already-established production `wo-note-025.yaml` + `wo-note-027.yaml` profiles in one runtime (`evidence/b8-log-021.log`), not the staged outputs authored by the AC-78(a) run. Those are useful component witnesses, but their composition does not establish `bootstrap → generated manifest/profile/tools → loaded disposable runtime → union/index/namespace/cross-source operations`. Keep the evidence and relabel it as component coverage; use one isolated disposable runtime for the correlated product-path check.
- AC-75 is now binary-current and much stronger, but its presentation should remain “shared-implementation component coverage,” not the exact named external scenario. The current delta witness stages a source addition on `dpdelta`, while the fresh evict witness seeds an `inventory` cache phantom already absent from source (`evidence/b8-log-014.log`; `evidence/b8-log-116.log`). WO AC-75 names one external flow: source change → delta upsert + watermark advance, then remove an entity at source → reconcile evict (`the work-order close bar`). The source-agnostic sync worker argument is valid corroboration, and the corrected UTC provenance repair is good work, but it remains an equivalence argument across corpora and initial states. Preserve it as assurance evidence and carry a deterministic single-corpus lifecycle harness as regression hardening rather than recycling the wave gate.

ALTERNATIVE FRAMING:
- Do not discard the landed witnesses or re-run AC-65..77. They are a useful closure baseline. Reframe AC-78(a) as an implementation correction: bootstrap must fail closed or return an explicit incomplete result when ingest, profile validation, activation, or loaded-tool verification is deferred.
- Build one disposable AC-78 acceptance harness with catalog builder present. For stocktrace and partline, run the canonical bootstrap, consume the generated manifests, validate and activate the generated profiles, boot one isolated runtime, verify the generated tools are listed, verify per-source indexes/namespaces, and execute the independent READ/MUTATE legs. This replaces the current inference chain with one attributable transcript.
- Clean the frozen index mechanically after the framing change. It currently says `FROZEN` / all gaps closed at line 11, then retains a stale `NOT yet freezable` status at line 42 before saying `NOTHING OWED` at line 46 (`evidence/b8-manifest-001.md`). Keep one generated status block and distinguish direct raw transcripts from markdown witness summaries.

DONE=GATE-B8-ROUND4-AC65-78-ADVISORY-REVIEW-20260202

B8_bootstrap_terminals_readonly_fix_proposal_review

2026-02-02T22:27Z · fix-proposal review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3):
- The D1 terminal model still conflates two materially different states: deferred authoring versus failed activation. Current bootstrap masks both missing catalog builder and unhealthy runtime while still printing “Source Onboarding COMPLETE” (`provision/wo-note-024.sh:748-753`, `:1064-1076`, `:1136-1146`), so the proposal is right to split terminal names. But once `--activate` mutates `CORE_PROFILE_PATHS`, restarts runtime, and then health/tools-list verification fails, that is not just `AUTHORED-INCOMPLETE`; it is an attempted activation failure in a possibly changed runtime. Treating `runtime-health` as another ledger deferral risks preserving the same false-surface problem under a softer name. AC-78’s bar is loaded runtime, union tools, and independent paths (`the work-order close bar`), so `ONBOARDED` should require post-restart `registry/list`; an attempted activation that misses that bar should be a loud activation-failed path with rollback/state reporting, not a generic authored-incomplete path.
- `--activate` is the riskiest part of the approach and is underspecified for the multi-source product case. The current script explicitly tells the operator to hand-edit single-source versus multi-source `CORE_PROFILE_PATHS` (`provision/wo-note-024.sh:1140-1144`). “Append the new profile to CORE_PROFILE_PATHS” must be idempotent, preserve existing profiles, avoid duplicates, and avoid clobbering a production compose file while the #104 witness is supposed to use an isolated disposable runtime. Without that contract, two successful bootstrap runs can still fail the actual AC-78 shape: both generated profiles live in one runtime and `registry/list` exposes their union concurrently (`the work-order close bar`).
- The read-only schema fix is directionally correct, but the validation/witness framing can accidentally weaken the close-bar. Today `the validate module` always synthesizes a `CommandClass::Write` / `CommandBinding::Write` and drives write-governance layer (`src/the validate module`), while `Operations.write_entity` is mandatory (`src/the schema module`) and `the write_ops module` assumes it exists (`src/source the write_ops module`). Skipping write legs for a read-only profile is necessary, but AC-78(f) still needs an actual stocktrace MUTATE and a partline READ in the same runtime. The implementation should make the read-only witness explicit: partline has no write surface and rejects any hand-authored write tool at registry load, while stocktrace still proves the write/write-governance layer path. Otherwise the new `Option<OpDef>` can make “no write attempted” look like the same evidence as “write path governed independently.”

ALTERNATIVE FRAMING (how I would shape it differently):
- Model the bootstrap result as three operational states even if the public close-bar only names two success-ish terminals: `AUTHORED-INCOMPLETE` for deliberate deferrals before activation, `ONBOARDED` only after catalog validation + profile activation + healthy runtime + `registry/list` union verification, and `ACTIVATION-FAILED` when activation was attempted but the runtime did not prove healthy/listed. The third state is not a resubmit loop; it is the honest failure case AP-#19 requires.
- Keep production bootstrap authoring side-effect-light by default. For the acceptance harness, prefer an isolated compose override or generated env file that sets the full `CORE_PROFILE_PATHS` vector for both generated profiles, then boot/restart that disposable runtime and verify `registry/list` from the same runtime. If direct compose mutation is retained, specify idempotent parse/update behavior and a rollback/story for failed activation.
- For D2, use `Option<OpDef>` as the profile truth, not a separate `read_only` flag, but make every witness capability-aware: read-only profile parses with no `write_entity`, no write-class generated tool appears, a deliberately planted `CommandClass::Write` under that source fails registry/profile consistency, and a write-capable profile still exercises the existing write-governance layer bracketed-write path.
DONE=B8-BOOTSTRAP-TERMINALS-READONLY-FIX-PROPOSAL-REV-20260202

B8_step4_ingest_rerun_review

2026-02-03T00:46Z · fix-proposal review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- The proposed loaded-tools discriminator names the wrong cache store primitive and is still short of the AC-78 serving bar. Source creates the index registry indexes with `FT.CREATE` (`the platform/src/cache the entities module`) and the established AC-78 witnesses prove them with `IDX-LIST`, not `EXISTS` (`evidence/b8-witness-004.md:29`, `observations/sent/wo-witness-007.md:21-22`). A literal `cachectl EXISTS {ns}:idx:{source}:{type}` risks false negatives for real the index registry indexes; replacing it with `IDX-LIST`/`IDX-INFO` proves AC-78(c) index creation, but not AC-78(f) serving. The runtime serving proof is the current-process resource map: a `registry/dispatch` that does not hit `ReadEngine: no resources registered for source` (`the platform/src/the read module`) or a current boot `profile loaded/source_count` signal tied to the recreated service instance.
- The `restart` -> `up -d` replacement is too broad unless it forces a process refresh. `wo-note-024.sh` Step 5 writes command definitions and restarts because `CommandRegistry::load` scans disk only at process boot (`the platform/provision/wo-note-024.sh:1082-1088`, `the platform/the registry module`); plain `stackctl up -d runtime` can no-op when only bind-mounted tool files changed. Step 6 also has an idempotent path where `CORE_PROFILE_PATHS` is already present and no compose config changes (`the platform/provision/wo-note-024.sh:1147-1157`), so `up -d` can leave the old registry/runtime mapped while the gate runs. The load-trigger fix is sound for env changes, but it needs either `up -d --force-recreate runtime` at the gate boundary or a split helper that uses recreate when the profile vector changes and a real restart/recreate when only registry contents changed.
- The source/kind fallback still needs an explicit ambiguity contract. AC-96 requires non-interactive onboard to produce an runtime-ingestible manifest from the config/spec path (`the work-order close bar`), while the current config loader has only connectivity fields (`the platform/provision/wo-note-024.sh:329-412`) and the catalog builder requires both `--source` and `--kind` for Pass-A (`the platform/catalog builder/the main module`). If convention fallback sees both `<source>wo-note-043.yaml` and `<source>wo-note-044.yaml`, or `source_kind` disagrees with the file selected, source-spec-first selection becomes a silent policy decision. That is anti-pattern #18 territory (`wo-note-045.md §6`): hardcoded values masquerading as derived. Convention fallback is acceptable only if it warns on use, fails loud on ambiguity/mismatch, and classifies missing vs inaccessible vs ingest-failed separately.

ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Treat ED-46 as three independently witnessed invariants: Pass-A catalog produced from a resolved `(kind, source, out)` triple; the runtime process was actually refreshed onto the intended `CORE_PROFILE_PATHS`; and the source is serving through the current runtime, not merely registered on disk.
- Implement one bootstrap reload helper that always records the pre/post service instance id, health result, and reason. Use forced recreate for activation/rollback or any gate that must prove a new env/runtime, and use restart/forced recreate for registry-only reloads where compose config did not change.
- Make the gate layered: `registry/list` contains `${source}.*` (registration) AND `IDX-LIST`/`IDX-INFO` contains the exact per-source index for AC-78(c) AND a minimal `registry/dispatch` or boot-readiness probe proves the current process has that source in its loaded resource map. Keep `AUTHORED-INCOMPLETE` only for genuinely missing authoring inputs; inaccessible paths, ambiguous sources, failed reloads, and failed ingest should fail loud or go to `ACTIVATION-FAILED` as appropriate.
DONE=B8-STEP4-INGEST-RERUN-REVIEW-20260203

B8_step4_ingest_invocation_fix_proposal_review

2026-02-03T01:17Z · fix-proposal review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- approach unchanged — prior holes stand/dispositioned. The prior review's objections remain the right pressure for this packet: Step 4 must not silently turn filesystem convention into product authority; missing source spec, inaccessible source/mount, and ingest failure must remain separate terminals; and the bootstrap Step 4 should execute a resolved `(kind, source, out)` triple rather than own source-policy discovery. Anchors: WO AC-78(a) requires bootstrap to onboard both shapes successfully (`the work-order close bar`); AC-96 requires the non-interactive path to produce an runtime-ingestible manifest (`the work-order close bar`); the current malformed caller is `catalog builder ingest "${SOURCE_NAME}"` with soft-swallowed failure (`provision/wo-note-024.sh:793-803`), while the CLI requires explicit `--pass`, `--source`, `--kind`, and `--out` (`catalog builder/the main module`).

ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Prior alternative framing stands: make explicit `source_spec`/`source_kind` authoritative for non-interactive onboarding; allow convention fallback only with a loud warning and no ambiguity; classify `spec-missing` as `AUTHORED-INCOMPLETE`, but make inaccessible/mis-mounted sources and failed ingest fail loud; keep Step 4 as a pure executor after the ingest triple has been resolved.
DONE=B8-STEP4-INGEST-INVOCATION-FIX-PROPOSAL-REVIEW-20260203

gate_b8_round5_ac65_78_advisory_review

2026-02-03T02:44Z · gate round · gate round 5 · verdict: proceed

BOTTOM-LINE: proceed

ADVISORY REVIEW:
- The round-5 packet resolves the round-4 approach defect. AC-78(a) is no longer a composed inference or false-success terminal; it has a single attributable product-path witness with real ingest, activation by force-recreate, a 3-layer loaded/serving gate, read-only enforcement, multi-source union, and production untouched. That is the right closure shape.
- The main remaining pressure is wording discipline around carry-forward items. The release-compose `/seeds` mount gap (#144), ED-46 clean induced `ACTIVATION-FAILED` exit-3 edge, and Step-5 `set -e` edge are registered residuals. Do not let final prose say every ED-44/ED-46 terminal and packaged-release onboarding path is runtime-proven; say the healthy ONBOARDED path is proven and those edge cases are registered non-blocking residuals.
- AC-75 is now framed correctly as shared-implementation component coverage. Keep that label. The current evidence proves the three sub-bars on the shipping implementation, but not a single one-corpus narrative flow; the deterministic single-corpus lifecycle harness belongs in regression hardening, not in the wave-gate recycle loop.
- AC-73/74/76 still rely on older raw witnesses plus the §B12 independence attestation. That is acceptable as a binary-currency argument, but final closure should call them "attestation-current" rather than "fresh runtime re-run" cells.

ALTERNATIVE FRAMING:
- Use this final handoff sentence: "§B8 is witness-complete on AC-65..78; AC-78(a) is directly witnessed as real ONBOARDED on the disposable product path; AC-75 is shared-implementation component coverage; named residuals are carry-forward hardening, not gate blockers."
- For AC-78(a), keep the evidence hierarchy explicit: ONBOARDED happy path direct runtime; D2/F-3 read-only guard direct runtime; AUTHORED-INCOMPLETE negatives direct runtime; ED-46 exit-3 induction and release-compose `/seeds` mount carry-forward.
- For AC-75, keep the cross-corpus disclosure and the single-implementation rationale in the final gate packet rather than rewriting it as a single exact scenario witness.

DONE=GATE-B8-ROUND5-AC65-78-ADVISORY-REVIEW-20260203

amendment_batch_a_b8_mechanical_review

2026-02-03T05:21Z · amendment review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- approach unchanged — prior holes stand/dispositioned. B8-01 still depends on B8-02 because `_reload_runtime` can trip `set -e` before the exit-3 terminal (`provision/wo-note-024.sh:1170`, `:1215-1216`, `:1259`, `:1416-1422`); B8-03 still needs the release package contract, not only a compose volume (`deploy/wo-note-033.yaml:115-122`, `deploy/wo-note-032.sh:7-16`, `:329-345`); B9-01 should remain verify-only unless a strict name sweep finds concrete offenders.

ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Prior alternative framing stands: sequence B8-02 before B8-01; treat B8-03 as compose + package-layout/preflight/docs + witness; keep B8-04 harness-only; close B9-01 by evidence unless the sweep finds actual files to rename.
DONE=AMENDMENT-BATCH-A-B8-MECHANICAL-REVIEW-20260203

item_b8_05_auth_mode_default_arm_review

2026-02-03T14:55Z · item review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES:
- The proposed default arm in the Step 3 auth block fixes the visible `set -u` crash, but it is a late validation boundary. `AUTH_MODE` is loaded from config in Step 1 alongside fields that already get immediate validation (`wo-note-024.sh:369-387`), while credential handling treats any non-`none` value as requiring `PROVISION_SOURCE_CREDENTIAL` before Step 3 (`wo-note-024.sh:428-437`). That means an invalid `auth_mode` can still be misclassified as credentialed auth and fail with the wrong complaint before reaching the new case arm. The primary validation should happen at config ingestion; the Step 3 default arm is still useful as defense in depth.
- The witness framing is too outcome-thin if it only asserts message, exit 1, lock release, and valid `source_key` regression. The current crash occurs while expanding a heredoc after `cat > "${profile_path}"` has already opened the output file (`wo-note-024.sh:699-701`), so a bad mode can leave a partial or truncated profile before failing. The evidence should explicitly prove that bogus `auth_mode` leaves no profile artifact and does not store or rotate credentials (`wo-note-024.sh:762-771`), otherwise the amendment may improve the terminal message while leaving state corruption unexamined.
- The scope argument leans too heavily on ED label matching. This is simpler and stronger as ordinary config-domain validation under AC-78(a): unsupported `auth_mode` is invalid input on the product path and should fail loud with exit 1. Avoid broadening this into a terminal taxonomy decision or treating the previous unbound-variable failure as equivalent to an honest fail-loud terminal; it failed, but at the wrong boundary and with poor state-safety guarantees.

ALTERNATIVE FRAMING:
- Add a small `validate_auth_mode` boundary where config is ingested, using the same allowed set as profile rendering: `none | source_key | bearer | session`. Call it immediately after `AUTH_MODE="$(_cfg auth_mode "none")"` and any interactive/auth-mode assignment path. Keep the Step 3 `*) die ...` arm as a defensive assertion that rendering cannot silently omit auth YAML.
- Shape the evidence around boundary behavior instead of the symptom: invalid mode with no credential should report unsupported `auth_mode`, not missing credential; invalid mode with a credential should still report unsupported `auth_mode`; no profile file should be created or modified; no credential should be stored or rotated; valid modes should still render their expected auth block.

DONE=ITEM-B8-05-AUTH-MODE-DEFAULT-ARM-REVIEW-20260203

item_b8_06_flatpkg_decouple_fixshape_review

2026-02-03T16:38Z · item review · verdict: reconsider-approach

BOTTOM-LINE: reconsider-approach

HOLES:
- The proposal undercounts the dev-root couplings. The named axes cover catalog builder, seeds, and compose, but bootstrap also authors/reads profile, tool, staged-tool, and catalog artifacts from `PROJECT_ROOT`: `PROFILES_DIR`/`COMMANDS_DIR` are fixed at startup (`provision/wo-note-024.sh:36-42`), the profile is written at `:700`, catalogs are verified at `:885`, Step 4b uses dev-root catalog/catalog builder/staging paths at `:923-925`, and command definitions are written under `COMMANDS_DIR` at `:1033`. Release compose mounts package-local `profiles/`, `tools/`, `schema/`, `catalogs/`, and `seeds/` (`deploy/wo-note-033.yaml:81-88`, `:116-128`). A clean-host package onboard can still write outside the package or fail to load generated assets unless the fix re-roots every bootstrap artifact path, not just the three highlighted axes.
- Auto dual-layout detection is the wrong default for this surface. Current bootstrap derives `PROJECT_ROOT` from the script location (`provision/wo-note-024.sh:36-37`); the proposal says FLAT-PKG if a sibling-of-`SCRIPT_DIR` `catalog builder` exists, while also asking whether packaging must ship `wo-note-024.sh` plus `provision/` helpers. Those shapes conflict: root-level `wo-note-024.sh` makes `SCRIPT_DIR` the package, but `provision/wo-note-024.sh` makes the sibling binary check look in `package/provision/catalog builder`. In dev/package staging, symlinked binaries can also make dev and flat signals coexist. This is a silent-wrong-root hazard against TW-5/AC-94's clean package claim.
- The approach misses launcher-instance coupling. Bootstrap targets compose commands through its own `STACK_FILE`/`PROJECT_ROOT` and defaults `STACK_PROJECT_NAME` to `the platform` (`provision/wo-note-024.sh:197-199`, `:873-876`, `:1206`, `:1361-1364`). The release launcher starts the stack with its own `NS`, `PACKAGE_DIR`, `STACK_FILE`, and `--project-name`/`--project-directory` contract (`deploy/wo-note-032.sh:150-166`). A package bootstrap has to target the exact running launcher instance; adding `wo-note-033.yaml` and `CORE_PROFILE_PATHS` does not by itself prove it will find the right secrets service, mutate the right compose file, or reload the right runtime service instance.

ALTERNATIVE FRAMING:
- Treat flat-package onboarding as an explicit package mode, preferably via the release entry point: `wo-note-032.sh onboard --config <answers> --activate` delegates to bootstrap with `--package-dir`, `--ns`, and the resolved release compose. If bootstrap remains directly callable, require `--package-dir <dir>` for flat mode and fail loud unless that root contains the complete package layout.
- Replace scattered path choices with one resolved layout object: `stack_file`, `project_directory`, `asset_root`, `profiles_dir`, `commands_dir`, `catalogs_dir`, `seeds_dir`, `catalog builder_bin`, and namespace/state source. Dev mode populates it from the repo; package mode populates it from the explicit package root. The render/ingest/activate steps then consume that object only.
- Make the witness prove boundary behavior: true clean host, no repo, no `target/release`, no `provision/` dependency unless intentionally packaged; launcher starts namespace N; onboard targets that same namespace; generated profile/tool/catalog files land inside the package; `CORE_PROFILE_PATHS` gains the new package profile; registry/list exposes the new source; no writes occur in the parent directory or repo; dev-layout AC-78 harness remains unchanged.

DONE=ITEM-B8-06-FLATPKG-DECOUPLE-FIXSHAPE-REVIEW-20260203

gate_b8_ac65_78_all8_substantive_advisory_review

2026-02-04T01:08Z · gate round · gate round 6 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

SCOPE READ:
This is sound as a pre-Bnew substance review, not as the final wave-gate firing. The B8 AC-65..78 runtime basis remains the shipping binary `build-4471`; the all-8 corrective fold is script/deploy only; the Bnew binary-currency re-cite and one spot-check remain the honest final frame. I do not see a substantive evidence hole that requires reopening B8 before Bnew.

HOLES / FRAMING RISKS:
- ITEM-B8-06's "4/4 PASS" citation is overcompressed. The manifest points the whole 4-arm claim at `evidence/b8-note-010.md`, but that file directly contains only A1/A2: flat-package onboard and package-local writes. A3 both-roots loud-die and A4 dev no-regression are in `evidence/b8-witness-007.md`, `evidence/b8-witness-011.md`, and `evidence/b8-witness-023.md`. The substance is covered, but the manifest cell should cite the close summary or the direct A3/A4 witnesses instead of asking a reader to infer them from FINAL_A1.
- The "clean-host flat-package" wording is slightly stronger than the final transcript. FINAL_A1 proves package-authoritative bootstrap/onboard: package `wo-note-024.sh`, package compose during bootstrap, package `/seeds`, package-local profile/catalog/tool writes, and 3-layer loaded gate. But its stack stand-up line still shows `runtime_launcher up` using the repo compose path (`the platform/deploy/wo-note-033.yaml`) while binding the package. That is enough for AC-78(a) package onboard substance, but it should be framed as "package-authoritative onboard on an isolated release instance" unless the Bnew spot-check starts the instance from the package compose path too.
- Do not use the bootstrap display line `Operations in catalog: 0` as close evidence. The same transcript shows Pass-A ingesting 7 seed calls and the loaded-gate serving the generated tool, so this looks like a reporting/counting defect rather than a close-bar failure. The close basis should be Pass-A exit 0, catalog produced, authored tools, and L1/L2/L3 loaded-gate.
- ITEM-B8-05 is directly witnessed for non-interactive config input. That is the important failed domain in this packet and the witness is clean: unsupported `auth_mode` dies early and a valid `none` config proceeds past validation. If the manifest keeps saying "after both assignment sites," keep it as a code-location claim plus config-mode witness, not as a separately exercised interactive-mode transcript.

ALTERNATIVE FRAMING:
- Call the current state "B8 substance-complete, Bnew-recite-ready" rather than "B8 wave-gate fired." That aligns the manifest's own assembly-only note with the operator's request for a pre-Bnew substantive read.
- For B8-06, split the claim into three evidence classes: (1) FINAL_A1 proves package-authoritative onboard and package-local writes; (2) WITNESS_CLOSE/direct agent files prove both-roots and dev no-regression arms; (3) Bnew spot-check should exercise the exact final packaging launch shape, preferably `runtime_launcher up/onboard` against the package compose path, so "clean-host package" is pinned without relying on repo-compose equivalence.
- Keep AC-75 as shared-implementation component coverage plus discharged regression hardening, and keep AC-73/74/76 as attestation-current. The manifest is already honest on those points; do not spend the Bnew re-cite trying to make old raw witnesses look fresh.

ADVISORY VERDICT:
Proceed with the Bnew re-cite path, but clean the B8-06 citation/framing before treating the packet as operator-facing closure text. I would not force a new B8 rework loop on the current evidence.

DONE=GATE-B8-AC65-78-ALL8-SUBSTANTIVE-ADVISORY-REVIEW-20260204

b9_gate_packet_draft_advisory_review

2026-02-02T20:06Z · packet review · verdict: reconsider-approach

BOTTOM-LINE: reconsider-approach

HOLES (strongest objections to the APPROACH; max 3, highest severity first; advisory only):
- The proposed “one frozen authoritative artifact” is not actually frozen or amendment-aware. `evidence/b9-manifest-001.md:6` still labels itself a `the dev lane draft for team-lead freeze`, while the packet presents it as ready to activate. More importantly, WO §B12 re-opened AC-94/95 with stricter lifecycle bars (`the work-order close bar`), but `evidence/b12-manifest-001.md:9-11,22-23` still carries AC-94 catalog builder-package execution as `PENDING(the dev lane)` and AC-95 witness refs as `TBC`. Later repo-root `evidence/b9-note-001.md` sections describe the stack-wide sideload and retained re-up probes, so the likely issue is stale indexing rather than absent implementation; however, the B9 matrix cites the older baked-era `b9-note-005.md` plus `task #26`, not a direct current raw lifecycle transcript. AC-100 has the same canonicality problem: the matrix row still states the superseded one-command/pre-wired containment framing (`b9-manifest-001.md:18`), while ED-40 replaces it with the trusted-extension-boundary and dev-authored-hook framing (`the work-order close bar`). Do not activate a gate from a manifest that is neither final nor resolved against amendment precedence.
- AC-101 collapses a four-path empirical close-bar into a three-terminal enum check. WO §B9 AC-101 requires `proceed→Committed`, `refresh-from-source-and-replay→Committed`, `replay-exhausted / strict-drift→Stale`, and `GovCheck-fail→Rejected`, with the mock-source harness drift/exhaust forcing each path (`the work-order close bar`). The matrix cites only one generic `Committed`, one `Rejected`, and one `Stale` result (`evidence/b9-manifest-001.md:19`). The architect verification explicitly notes that the successful refresh-and-replay branch was not separately isolated (`evidence/b9-note-004.md`, Notes). The enum has three variants, but the WO deliberately asks for four behavioral paths. Stage a drift that resolves after refresh and externally capture the replay-then-`Committed` path separately from straight proceed.
- The draft still substitutes proxies for named runtime observations in AC-97 and AC-99. AC-97 requires distinct per-source cadences to be **honored** (`the work-order close bar`), but the matrix closes it with profile values plus a code read and admits no cadence-firing witness (`evidence/b9-manifest-001.md:15`; `b9-note-006.md:17-19`). AC-99 requires cache-only reads with zero live source contact (`the work-order close bar`), but `b9-log-006.log` infers zero source adapter calls from unchanged sync worker budgets plus structural reasoning. That is weaker than the AC-69 standard: AC-69 observed a source-side the mock-source harness journal delta of zero and used unchanged budget as corroboration (`evidence/b8-witness-002.md:24-31,64-79`). Use a controlled source journal or egress observer for AC-99, and accelerated disposable profiles with distinct short cadences for AC-97 so runtime firing can be observed without waiting a week.

ALTERNATIVE FRAMING:
- Treat this draft as an evidence-assembly plan, not an activatable the external gatekeeper packet. Build one amendment-resolved §B9 sub-bar matrix after applying ED-40 and §B12 reopen precedence. Every cell should cite a current raw external transcript; rolling architect notes, task IDs, and repo-root summaries remain corroboration only.
- Split release closure into explicit lifecycle cells: three code-free substrate images, sideloaded runtime ready-line, sideloaded ephemeral catalog builder invocation, concurrent isolated instances, clean purge teardown, and retained `down`→`up` secret reuse with the same stored bearer.
- Split behavior closure by path rather than terminal label: AC-101 gets four externally forced branches; AC-97 gets scaled cadence-firing observations; AC-99 gets source-side zero-call measurement analogous to AC-69.

DONE=B9-GATE-PACKET-DRAFT-ADVISORY-REVIEW-20260202

gate_b9_freeze_ac94_104_advisory_review

2026-02-03T00:39Z · gate round · gate round 1 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; advisory only):
- The freeze packet says every cell is a current raw external witness on the shipping binary, but the manifest still mixes witness baselines without a release-truth paragraph. AC-97/99/101 are explicitly on `build-4471`; AC-95 is a launcher re-witness at git `build-4472`; AC-102/103 are described elsewhere as witnessed at `build-4473` with a no-touch caveat. That is likely acceptable, but it should be framed as baseline-specific runtime witnesses plus a changed-path/no-rerun argument where applicable, not a blanket "all on the shipping binary" claim.
- AC-98 remains the weakest provenance row in the single handoff artifact. The manifest points to `b9-note-003.md §01:10Z` for registry/list union and per-source namespace isolation, while the packet asserts raw current evidence. A rollup can be useful, but the frozen matrix should either cite the raw registry/list / namespace transcript directly or explicitly mark this as an architect-rollup-backed cell. Do not make the external gatekeeper reconstruct the raw chain from historical notes.
- The manifest still carries stale signed history that says not-yet-freezable, missing `b9-note-001.md`, and AC-95 open before later sections discharge it. The top matrix plus the adjudicator #131 are clear enough, but the artifact is easy to misread if a reviewer scans the body instead of honoring the current block. That is a packaging risk, not an implementation risk.

ALTERNATIVE FRAMING:
- Open with a compact "current evidence contract" table: AC, sub-bar, witness baseline, raw artifact, evidence class, and changed-path/no-rerun note if the witness is not from the final shipping artifact.
- Split AC-98 into direct sub-bars: four manifests loaded, registry/list union, per-source namespace evidence, and no collision. Put the raw transcript path in the row; leave `b9-note-003.md` as corroboration.
- Move pre-fix the adjudicator/dev history under a clearly superseded appendix, or add a one-line instruction before it: "Appendix only; current state is lines 9-30 plus the adjudicator #131." This keeps the audit trail without letting old owed-state language compete with the freeze claim.

DONE=GATE-B9-FREEZE-AC94-104-ADVISORY-REVIEW-20260203

gate_b9_freeze_ac94_104_round2_advisory_review

2026-02-03T00:46Z · gate round · gate round 2 · verdict: proceed

BOTTOM-LINE: proceed

ADVISORY REVIEW:
- The round-2 packet folds the three round-1 packaging holes. The manifest now opens with a baseline-honest evidence contract, AC-98 is no longer disguised as a standalone raw transcript, and the stale signed history is quarantined under a superseded appendix instruction. That is the right framing for a freeze handoff.
- The only remaining weakness is intentional and now visible: AC-98 is still architect-rollup-backed for the §B9-specific `registry/list=22` claim, with §B8 raw namespace-isolation evidence as corroboration. That is acceptable as long as the final gate language keeps the "rollup-backed" label and does not relabel AC-98 as a direct raw transcript.
- Two small wording nits remain but are not worth another B9 loop: the manifest's general header still says each AC maps to a current raw external witness, while AC-98 is explicitly rollup-backed; and the AC-96 row still carries stale "b9-note-001.md does not exist" wording even though the current primary evidence is `wo-log-043.log` and the row treats the stale citation as superseded. Neither changes the evidence posture.

ALTERNATIVE FRAMING:
- Treat the top evidence-contract table as the source of truth for the external gatekeeper. If any final verdict prose is written, say: "§B9 is closed on baseline-specific current evidence; AC-98 is rollup-backed with raw namespace corroboration; historical appendix text is audit trail only."
- Keep AC-98 in its own evidence class rather than trying to promote it. The honest label is stronger than another late packaging churn cycle.
- If the manifest is touched for editorial cleanup, remove the stale AC-96 parenthetical and soften the header from "each AC current raw" to "each AC current evidence." No re-review should be needed for that.

DONE=GATE-B9-FREEZE-AC94-104-ROUND2-ADVISORY-REVIEW-20260203

gate_b10_ac105_110_advisory_review

2026-02-02T20:43Z · gate round · gate round 1 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; advisory only):
- AC-110 conflates a repaired semantic-regression witness with the broader ingestion-capability proof. The locked §B10 criterion still asks for an end-to-end fake source ingest that enumerates ALL commands and captures success+error response shapes per command (`the work-order close bar`). ED-39 correctly tightens semantic truthfulness: only `negative + source_failure + validated` may project into `failure_shapes[]` (`the work-order close bar`). The current live regen is useful and honest, but it produces `failure_shapes: []`; its only negative probe is `get_unit.neg.not_found @200 = negative/source_success/unproven` (`evidence/wo-note-040.md`). That proves removal of the fabricated shape, not live error-shape capture. `evidence/b12-note-006.md` unit-tests the body-error projection mechanism, but the packet should not substitute that unit proof for the named §B10 E2E capability cell. Preserve both truths: mark the semantic-regression sub-bar closed, and add a controlled fake read failure (for example `BodyFieldEq` HTTP-200 body-error or an HTTP 4xx) to demonstrate one validated projected failure shape while retaining the accepted-bad-input `unproven` case.
- AC-108's new source-side witness is strong but narrower than the row it is used to close. The criterion requires a qualified source-X tool to reach only source-X's credential, endpoint, commands, validated manifest, and per-source estate (`the work-order close bar`). `evidence/b10-witness-001.md` and raw `b10-log-005.log` dispositively show two live source adapters issuing source PUTs with distinct own credentials and zero cross/foreign keys. That closes credential isolation and materially corroborates endpoint routing. It does not externally observe command-set isolation, validated-manifest selection, or `{ns}:entity:{source}:*` estate isolation. Keep the witness, but stop calling it the “EXACT close-bar” for the whole AC. Split the AC-108 matrix into credential, endpoint, command/manifest, and estate sub-bars; credit raw source journals where available and label source reads as corroboration.
- AC-109's raw transcript exercises malformed YAML and unreachable-probe warnings, while the criterion says malformed/partial spec plus probe failures (`the work-order close bar`). `evidence/b10-log-009.log` is good evidence for graceful malformed-spec exit and visible network-failure continuation. The shipping-source attestation notes the separate unknown-`call_id` graceful-skip branch (`evidence/wo-note-009.md:85-94`), but that is a source read, not the current external transcript presented by the manifest. Distinguish malformed from parseable-but-partial input. A small partial fixture that triggers the intended warning or validator halt would make the robustness row match its own wording without changing the mechanism.

ALTERNATIVE FRAMING:
- Treat the §B10 artifact as a sub-bar evidence matrix, not six indivisible PASS labels. AC-105/106 and the AC-107 live collision abort are direct. AC-108 should expose four isolation dimensions. AC-109 should expose malformed, partial, and probe-failure cases. AC-110 should expose both semantic truthfulness and live capture capability.
- For AC-110, preserve the regenerated `failure_shapes: []` artifact as the accepted-bad-input regression witness, then add one body-aware proven fake failure and persist the resulting enriched manifest excerpt as durable evidence. This demonstrates that the catalog builder omits unproven shapes and captures proven ones.
- Proceed with the implementation direction. These are evidence-framing and targeted witness additions, not grounds for a resubmit loop. As packaging cleanup, remove or annotate the appended stale the adjudicator text in `evidence/b10-manifest-001.md:34-66`: it still describes AC-108 as pending and the binary-currency attestation as in flight even though the rebuilt header and landed attestation supersede those statements.

DONE=GATE-B10-AC105-110-ADVISORY-REVIEW-20260202

gate_b10_regate_ac105_110_advisory_review

2026-02-02T21:13Z · gate round · gate round 2 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; advisory only):
- AC-110's new live witness closes the missing projection example, but the manifest still overstates it as the full per-command capability bar. WO §B10 AC-110 asks to capture success+error response shapes **per command** (`the work-order close bar`). `evidence/b10-log-011.log` is a good source-side witness: `get_unit` has validated success, retained accepted-bad-input `unproven`, and one validated projected 404 failure shape; VR-13 validates the cross-section. It also explicitly reports `update_item: status=documented`, while `list_items` has success only. ED-39 correctly keeps mutation probes separate (`the work-order close bar`), but it does not turn one read-call error capture into error-shape coverage for every probe-safe command. Credit this as a live capability sample plus the semantic-regression closure. Either publish a per-call coverage table with unprobed states explicit or narrow the claim from “per command” to the ratified probe-safe capability actually demonstrated.
- AC-108 is better decomposed, but the endpoint row contains a factual over-claim and the manifest/estate legs remain corroborative rather than attributed source-X action witnesses. The frozen manifest says each credential-witness write landed on its own the mock-source harness journal / per-source base URL (`evidence/b10-manifest-001.md:15`), but that harness intentionally points **both** profiles at the same dedicated `the mock-source harness_ac108` endpoint (`evidence/b10-witness-001.md:13-18`; raw `…wo-log-161.log:10`). It dispositively proves credential-cache isolation, not distinct endpoint routing. The new W-1 journals are useful, but they sample sync worker history rather than correlate a qualified X write to endpoint X (`b10-log-006.log:9-15,46-50`). W-3 is an on-disk tools-dir/catalog-exists listing, not a runtime observation that X selected a validated X manifest (`:26-36`). The estate citation shows distinct prefixes and legacy residue, but its “cross-collision” search for keys containing both source names cannot detect X-shaped data written under Y's prefix (`b8-log-017.log:32-71`). Keep these as useful assurance evidence; do not label all dimensions externally witnessed at equal strength.
- The artifact called frozen still has avoidable citation/state drift. AC-110 cites durable artifacts under `_ac110_artifacts/`, while the landed files are under `_ac110_fixtures/` (`evidence/b10-manifest-001.md:22`; `evidence/b10-log-011.log`). AC-107 still cites a live `44 tools / 42 qualified` snapshot (`b10-manifest-001.md:13`), while the newer AC-108 W-2 capture lists a different staged runtime population (`b10-log-006.log:17-23`). This does not undo the collision mechanism, but a handoff artifact should distinguish witness timestamp/runtime scope from current inventory instead of blending snapshots.

ALTERNATIVE FRAMING:
- Publish three evidence strengths instead of flattening every sub-bar into `PASS`: **directly witnessed**, **capability-sampled**, and **structurally corroborated**. AC-108 credential isolation and AC-110 validated 404 projection are direct. AC-108 endpoint/manifest/estate are currently corroborated. AC-110 per-call coverage is partially sampled.
- Carry one compact source-X/source-Y contrast harness as follow-on hardening, not another resubmit loop: use distinct endpoints, baseline both source journals and both cache store prefixes, issue qualified X and Y actions, capture per-endpoint deltas, capture per-prefix deltas, and record the loaded validated-manifest digest per source adapter. That single correlated run would replace several inference chains.
- Proceed with the implementation direction. Before treating the handoff document as frozen, correct the AC-108 endpoint sentence, the `_ac110_fixtures/` citation, and the timestamp/scope labels on tool-count snapshots.

DONE=GATE-B10-REGATE-AC105-110-ADVISORY-REVIEW-20260202

gate_b10_round3_ac105_110_advisory_review

2026-02-02T22:04Z · gate round · gate round 3 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; advisory only):
- The disclosed dispatch hang should not be framed as unrelated to the AC path. The X/Y contrast exposed a real routing-boundary assumption: the write stream is namespace-scoped, one consumer is assembled from whichever profiles loaded successfully, and a partial-profile process can consume an intent for a data source it cannot execute. The current error path parks that entry without `XACK`, while reclaim runs only at startup (`the main module`, `the main module`, `the config module`, `src/the mod module`, `src/the mod module`). Stopping the three stray service instances was the right witness cleanup, but it proves the happy path only under a clean-estate/capable-consumer assumption. Keep the completed B10 witness; carry the product fix as an owned pre-`/wo_close` item and state the assumption explicitly. The pending R-1 design still needs a safe distinction between generic stale-work recovery and claim-busy retry; a blanket short-idle reclaim loop can steal legitimate long-running work.
- The AC-108 “direct” row compresses several contracts into one stronger claim than the transcript demonstrates. The X/Y run hashes `profiles/wo-note-041.yaml` and `profiles/wo-note-042.yaml`, while the WO language names isolated `catalogs/<source>.yaml`; the runtime loader evidence is for connectivity profiles, not a catalog-to-profile mapping. Also, `adapter_ready` is not source-tagged in `src/source the mod module`; the per-source `cache store_connected` events provide the useful corroboration. Finally, the same-value prefix checks directly prove opposite-prefix non-interference, not own-prefix landing. Own-path execution is supported by endpoint journal and verdict evidence. Narrow the row labels to those witnessed facts, or separately record the catalog validation/mapping and immediate cache store provenance needed for the broader formulation.
- The freeze artifact needs an explicit release-target boundary. The survivor X/Y witness ran against the still-open `13b` process after an `ED42` binary was rebuilt on disk; the later source delta includes `src/the main module`, `src/profile/the schema module`, and `src/the registry module`, which touch the profile/registry boundary relevant to AC-107 and AC-108. Do not call the result generically “current” without qualification. Pin this closure to the running `13b` baseline, or add a narrow changed-path attestation for `ED42`. A fresh full witness cycle is unnecessary unless that attestation finds behaviorally relevant drift.

ALTERNATIVE FRAMING:
- Treat `b10-log-007.log` as a clean-estate `13b` routing witness: distinct profile-declared endpoints, qualified X and Y command execution, and bidirectional cross-prefix non-interference. Preserve endpoint journal plus verdict evidence as the own-path proof.
- Separate three artifacts in the frozen narrative: connectivity profile selection, tool/catalog validation, and estate-prefix isolation. State which layer is runtime-loaded and which layer is validated earlier in the pipeline instead of using “validated manifest” as a catch-all.
- Record the rogue-consumer defect as a product-boundary item exposed by B10, not as a reason to recycle B10. The closeout contract should cover unique consumer identity or fail-fast isolation, terminal handling for permanently incapable consumers, and safe steady-state recovery for genuinely abandoned entries.
- Add a small release matrix to the handoff: witnessed runtime hash/version, rebuilt sideload hash/version, and whether changed AC-relevant paths were attested unchanged in behavior.

DONE=GATE-B10-ROUND3-AC105-110-ADVISORY-REVIEW-20260202

gate_b10_round4_ac105_110_advisory_review

2026-02-02T22:50Z · gate round · gate round 4 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; advisory only):
- The round-4 packet still over-credits ED-43 as closure of the product-boundary defect exposed by B10. ED-43 adds periodic reclaim and bounded handling for the claim-busy branch (`src/the mod module`, `src/the mod module`), but the actual rogue-consumer RCA also depended on partial-profile consumers joining the namespace write stream with the default consumer identity (`the main module`, `the main module`, `the config module`) and then hitting the no-source adapter write-governance layer error path, which still logs `NO XACK (will be reclaimed)` (`src/the mod module`). Periodic reclaim can reduce stuckness when a capable consumer eventually wins; it does not enforce capable-consumer membership or terminally reject an intent that a consumer can never process. Keep B10 on the clean-estate/capable-consumer witness, but do not present ED-43 as the full product-boundary cure until the seven-arm runtime witness and the duplicate/partial-consumer contract land.
- The release-target framing is improved but still easy to misread. The top of `b10-manifest-001.md` says each AC maps to the "CURRENT raw external witness," while the release matrix later says all B10 witnesses ran on in-memory `build-4471` and the rebuilt ED-42/ED-43 binary is not yet witnessed for B10. The changed-path attestation is a good no-rerun argument, but it is still an attestation, not raw runtime evidence for the rebuilt binary. Phrase the freeze consistently as "B10 witnessed on `build-4471`; later binary covered by changed-path attestation," and avoid using "current raw" to imply the rebuilt sideload has been runtime-witnessed.
- AC-108's rows are much better narrowed, but the summary still collapses the decomposed proof back into "AC-108 x4 all four dimensions directly witnessed." That is stronger than the row text: runtime connectivity-profile selection is directly witnessed, catalog/tool validation is cross-cited from earlier layers, and estate isolation is a composite of opposite-prefix non-interference plus endpoint/verdict own-path proof. The evidence is usable; the label should be "composite/direct-by-layer" rather than a flat all-dimensions direct witness.

ALTERNATIVE FRAMING:
- Treat the B10 closure as a stable `build-4471` clean-estate witness with a changed-path attestation for later code. That avoids another B10 loop while keeping runtime truth and release truth separate.
- Describe ED-43 as ownership and partial remediation of the exposed write-consumer recovery defect, not as completed proof that arbitrary partial-profile consumers are safe. The remaining contract should cover unique consumer identity, incapable-consumer fail-fast or terminal rejection, and the planned runtime witness.
- Split AC-108 into layer-specific evidence classes: direct runtime profile/endpoint/credential observations, composite estate proof, and cross-cited catalog/tool validation. That preserves the real strength of the X/Y harness without overstating what it measured.

DONE=GATE-B10-ROUND4-AC105-110-ADVISORY-REVIEW-20260202

gate_b10_round5_ac105_110_advisory_review

2026-02-02T23:00Z · gate round · gate round 5 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; advisory only):
- The packet is now cleaner on labels, but it still risks implying that the B10 story is fully closed once ED-43 is mentioned. It is not. ED-43 is ownership plus partial remediation for the write-consumer recovery defect (`src/the mod module`, `src/the mod module`), while the actual rogue-consumer condition also depends on join-time membership and consumer identity (`the main module`, `the main module`, `the config module`). The no-source adapter failure path still ends in `NO XACK (will be reclaimed)` (`src/the mod module`), which is recovery, not prevention. Keep the B10 witness as a clean-estate proof on `build-4471`, but do not let the manifest read as if ED-43 already solved incapable-consumer admission.
- The release-truth split is correct, but the manifest still asks the reader to hold two truths at once: runtime evidence is pinned to `build-4471`, while the rebuilt ED-42/ED-43 sideload is only covered by changed-path attestation. That is fine technically, but the narrative should be explicit that the attestation is a no-rerun argument, not a new runtime witness. Otherwise "single handoff artifact" can be misread as one proof for both binaries.
- AC-108 is now labeled `composite/direct-by-layer`, which is the right direction, but the summary needs to stay aligned with that decomposition. The evidence remains strongest when treated as separate layers: direct source-side credential isolation, direct endpoint routing, direct runtime connectivity-profile selection with cross-cited build-time catalog validation, and composite estate isolation from opposite-prefix non-interference plus endpoint/verdict own-path. If the summary collapses those back into a flat "all four dimensions" claim, the earlier framing problem comes back.

ALTERNATIVE FRAMING:
- Present B10 as closed on the witnessed `build-4471` clean-estate case, with ED-43 as the operational mitigation for the write-consumer symptom and the capable-consumer membership contract as the remaining separate item.
- Keep release-truth and runtime-truth in different sentences or table columns. That prevents the changed-path attestation from being mistaken for a second runtime witness.
- Keep AC-108 explicitly layered in the summary as well as in the rows. That preserves the actual strength of the X/Y harness without inflating one layer into all four.

DONE=GATE-B10-ROUND5-AC105-110-ADVISORY-REVIEW-20260202

gate_b10_round6_ac105_110_advisory_review

2026-02-03T00:37Z · gate round · gate round 6 · verdict: proceed

BOTTOM-LINE: proceed

ADVISORY REVIEW:
- The round-6 summary folds the three round-5 approach holes. The closure is now baseline-scoped to the witnessed `build-4471` clean-estate runtime, ED-43 is framed as write-consumer symptom recovery rather than incapable-consumer admission control, release-truth is separated from runtime-truth, and AC-108 stays decomposed by evidence layer in both the rows and the summary.
- The strongest remaining stress point is downstream misuse, not the manifest itself: a later closure artifact could still flatten this into "B10 closed on the rebuilt binary" or "ED-43 solved rogue membership." The current manifest prevents that by saying the rebuilt ED-42/ED-43 sideload is covered only by a no-rerun changed-path attestation and that the capable-consumer membership contract remains separate.
- AC-108 remains the place most likely to be over-read. The current framing is acceptable because it treats credential isolation, endpoint routing, connectivity-profile selection, build-time catalog validation, and estate isolation as separate clauses with different evidence classes. Do not let the final gate language collapse those back into a single direct runtime proof.
- The historical sections are noisy, but they are explicitly marked superseded and the current summary is at the top. That is good enough for this handoff; moving older folds into an appendix would be cleaner but is not worth another B10 loop.

ALTERNATIVE FRAMING:
- Use a single closure sentence: "B10 is closed for AC-105..110 on the witnessed `build-4471` clean-estate runtime; the rebuilt sideload is accepted by changed-path no-rerun attestation, not by a second runtime witness."
- Treat ED-43 as "recover parked write intents to a bounded typed terminal" and keep "capable-consumer admission / unique consumer identity" as the separate membership item.
- Describe AC-108 as four layer-specific proofs: credential direct source-side, endpoint direct runtime, runtime profile selection plus cross-cited catalog validation, and estate isolation as opposite-prefix non-interference plus own-path endpoint/verdict evidence.

DONE=GATE-B10-ROUND6-AC105-110-ADVISORY-REVIEW-20260203

b12_fixscope_review

2026-02-02T03:52Z · fix-proposal review · verdict: reconsider-approach

BOTTOM-LINE: reconsider-approach

HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- AC-110 points its remedy across a locked safety boundary. WO §B12 VR-P2 requires every Pass-B `call_id` to resolve to `read|list|get` and rejects `write|action` probes (`the work-order close bar`); the catalog builder enforces that contract by skipping write/action commands (`provision/catalog builder/the driver module`, `provision/catalog builder/the driver module`, `tools/source_ref_validator/the semantic_probe module`). Requiring Pass B to capture success and error shapes for write/action commands is not a completeness fix: it converts a non-invasive validator into a mutation-capable runner. Keep Pass B truth-validating for probe-safe commands and validate mutation shapes in the existing governed test-instance path under a separate close-bar.
- AC-114 closes the cited partial-snapshot phantom eviction, but it does not cover all eviction paths. The inbound event feed consumer can evict an out-of-collection record before acquiring the per-entity claim (`src/the inbound event feed_ingest module`) and before applying the monotonic stale-event check (`src/the inbound event feed_ingest module`). A stale inbound event feed can therefore delete a newer cached record without the serialization and timestamp defenses used by the upsert path. Scope AC-114 explicitly to snapshot-derived eviction safety and add a sibling close-bar that acquires the claim and performs the stale-event check before any inbound event feed delete or upsert.
- AC-94 identifies the complete current set of baked release executables: source inspection finds no fourth app image, and the remaining `COPY` instructions are the broker and catalog builder release service-stackfiles (`provision/secrets service/service-stackfile.release:43`, `provision/catalog builder/service-stackfile.release:29`). But removing the catalog builder `COPY` is only half of a sideload conversion. The release compose file mounts broker and runtime binaries but has no catalog builder service (`deploy/wo-note-033.yaml:51-83`), while launcher package validation does not require a catalog builder binary (`deploy/wo-note-032.sh:271-275`). Add an explicit release invocation for the ephemeral catalog builder with its binary mount and runtime mounts, then prove it on a clean-host package standup.

ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Split AC-110 into a non-invasive observation validator for `read|list|get` and a governed mutation-shape harness for `write|action`; do not weaken VR-P2 to make one runner serve both purposes.
- Define AC-114 narrowly as `snapshot-derived eviction safety`, then audit the distinct predicate-driven delete paths separately. Repair inbound event feed ordering with claim acquisition and monotonic validation before deletion.
- Treat AC-94 and AC-95 as one deterministic release-lifecycle exercise: enumerate every shipped binary and invocation route, prove sideload mounts on a clean host, and choose retained broker-secret reuse as the default re-up behavior. Reserve atomic rotation for an explicit operation rather than leaving an implementation-time `reuse|rotate` branch.

DONE=B12-FIXSCOPE-REVIEW-20260202

R1_write_consumer_claim_busy_fix_proposal_review

2026-02-02T22:04Z · fix-proposal review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3):
- Approach unchanged — prior holes stand/dispositioned. the adjudicator task #99 ratifies the original generic `MIN_IDLE` periodic `QUEUE-RECLAIM` sweep and upgrades its generic PEL delivery-count terminal from optional to required; it does not alter the mechanism reviewed in the prior the adversarial reviewer pass. The prior concerns therefore remain banked for the team-lead’s disposition: protect healthy long-running brackets from live-work reclaim, do not infer claim-contention exhaustion from an untyped PEL delivery count, and make periodic reclaim errors loud. No fresh the adversarial reviewer review loop.

ALTERNATIVE FRAMING (how you would shape it differently):
- Prior alternative framing stands: keep the claim-busy WARN, distinguish safe generic stale-work reclaim from fast claim-busy retry, preserve durable intents until cause-correct idempotent convergence, and treat any poison-entry terminal/dead-letter contract as an explicit cause-specific design. If the ratified generic-sweeper shape proceeds, the concurrency-tier diff verification and witness should add two live consumers, a healthy bracket longer than `MIN_IDLE`, non-contention no-XACK entries, and periodic-reclaim failure visibility.

DONE=R1-WRITE-CONSUMER-CLAIM-BUSY-FIX-PROPOSAL-REVIEW-20260202

gate_b12_ac94_115_advisory_review

2026-02-03T00:41Z · gate round · gate round 1 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; advisory only):
- The packet calls `b12-manifest-001.md` the single handoff artifact, but the artifact has not absorbed the late evidence the packet now relies on. The manifest matrix/status stops at AC-94/95/110/114/115 plus the pre-fix/post-fix AC-95 discharge; it does not fold ED-42 mount-all, ED-43 write consumer recovery, ED-45 secrets service quarantine, or the capable-consumer carry-forward resolution into the current matrix. Those may be valid closure inputs, but they should not live only in the inbox packet if the instruction is "read one frozen artifact."
- The release/binary story is currently too flat. The manifest header says `Binary: build-4471`, while the current B12 closure spans multiple component baselines: AC-114/ED-38 realrace on `build-4471`, ED-42 on its ephemeral `build-4474` build/package, ED-43 on the rebuilt `source-runtime-server` package hash, ED-45 on a rebuilt `secrets service`, and AC-95 on the ED-41 launcher re-witness. That is fine if framed as component-specific runtime witnesses, but not as one monolithic "shipping binary" statement.
- AC-115 is now a bundle of several distinct claims: inbound event feed claim/stale serialization, multi-inbound event feed mount-all/route isolation, write-consumer no-silent-drop recovery, and capable-consumer membership carry-forward. Keep those layers separate. In particular, ED-43's "7/7" witness includes an arm explicitly skipped/deferred to deploy time, and the incapable-vs-capable consumer timing arm remains source/trinity analysis rather than runtime witness. That does not have to block closure, but the packet should label it as carry-forward risk with a source-verified pivot, not witnessed behavior.

ALTERNATIVE FRAMING:
- Rebuild the frozen artifact as a component-baseline evidence table: AC/sub-bar, runtime or component baseline, raw artifact, evidence class, and whether the cell is direct runtime, source/trinity analysis, or carry-forward risk.
- Put ED-42, ED-43, ED-45, and the capable-consumer resolution into the AC-115/AC-95 rows or a current addendum before the historical the adjudicator sections. The inbox packet should then point to that artifact, not supplement it.
- Phrase AC-115 closure as: "direct runtime witnessed for inbound event feed/SW claim serialization and route isolation; direct runtime witnessed for write-consumer recovery/bounded terminal except the deploy-time live-PEL drain arm; capable-consumer membership is registered carry-forward because the no-source adapter path is source-verified no-XACK/drainable."

DONE=GATE-B12-AC94-115-ADVISORY-REVIEW-20260203

gate_b12_ac94_115_round2_advisory_review

2026-02-03T00:48Z · gate round · gate round 2 · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

ADVISORY REVIEW:
- The round-2 manifest folds the main packaging fixes: the component-baseline table replaces the flat `build-4471` header, ED-42/ED-43/ED-45 and the capable-consumer resolution are now in the artifact, and AC-115 is split into evidence layers instead of being treated as one undifferentiated PASS. That resolves the round-1 approach problem.
- The remaining provenance overclaim is the packet's "the adjudicator #131-verified" phrasing. #131 verifies the AC-95 post-fix witness; it does not appear to verify the late ED-42/ED-43/ED-45/capable-consumer fold. The manifest itself says "the adjudicator verify of the late-closure fold = pending (#49-class)." Keep the current evidence, but do not represent the whole B12 late fold as the adjudicator-verified unless that specific verification exists.
- AC-115 L3 still needs careful wording: `ED-43 sevenarm` is a useful witness label, but one arm is deploy-deferred and the incapable-vs-capable timing behavior is source/trinity analysis, not runtime. The current matrix says that; final gate prose should not compress it back to "7/7 runtime witnessed."
- The stale the adjudicator section is less dangerous now because the current table is explicit, but it is still not marked as strongly as the B9 appendix. If the artifact is touched, add a clear "appendix only; current state is the component-baseline table and current matrix" banner before the pre-fix `NOT freezable` text.

ALTERNATIVE FRAMING:
- Phrase the handoff as: "B12 is freezable on component-baseline evidence, with AC-115 carry-forward items explicitly named; AC-95 is the adjudicator #131-verified, while the late ED-42/43/45/capable-consumer fold is architect-folded unless separately re-verified."
- For AC-115 L3, say "direct runtime for claim-busy warning, periodic reclaim, live-work protection, and bounded typed terminal; deploy-time live-PEL drain deferred; incapable-vs-capable membership risk source/trinity-carried."
- Keep the component-baseline table as the controlling artifact. Do not use a single "shipping binary" or "all the adjudicator-verified" summary.

DONE=GATE-B12-AC94-115-ROUND2-ADVISORY-REVIEW-20260203

gate_b12_ac94_115_round3_advisory_review

2026-02-03T01:01Z · gate round · gate round 3 · verdict: proceed

BOTTOM-LINE: proceed

ADVISORY REVIEW:
- Round-3 closes the round-2 provenance gap. AC-95 is now scoped to the adjudicator #131, and the late ED-42/ED-43/ED-45 plus capable-consumer fold is scoped to the adjudicator #139. The component-baseline table and AC-115 layer split are the correct control surface for this packet.
- The main remaining hole is presentation risk, not evidence risk: the packet still says "all PASS" in shorthand while AC-115 includes named carry-forward items. The manifest is honest, but final gate prose must preserve that nuance: direct runtime for the named AC-115 runtime layers, deploy-deferred live-PEL drain, and source/trinity-carried capable-consumer membership risk.
- The appendix banner is mostly strong enough, but it now sits above both stale history and the current #139 verification section. Since the status block already cites #139 accurately, this is not worth another loop; just do not let a reader treat the appendix heading as downgrading #139.

ALTERNATIVE FRAMING:
- Use this one-line handoff: "B12 is freezable on component-baseline evidence; AC-95 is #131-verified, late ED-42/43/45 plus capable-consumer classification are #139-verified, and AC-115 carry-forward items are explicitly named rather than runtime-claimed."
- Keep AC-115 L3/L4 exactly split: runtime recovery behaviors are witnessed; live-PEL drain is deploy-deferred; membership hardening is carry-forward risk with a source-verified no-XACK/drainable pivot.
- In final closure, avoid generic "all AC-115 runtime witnessed" wording; cite the component-baseline table as controlling.

DONE=GATE-B12-AC94-115-ROUND3-ADVISORY-REVIEW-20260203

amendment_batch_b_b12_writeconsumer_review

2026-02-03T04:44Z · amendment review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- approach unchanged — prior holes stand/dispositioned. The prior review's objections remain: the packet anchors write consumer PEL/membership work to `the work-order close bar`, but that row is inbound event feed-eviction ordering; ITEM-B12-01 mixes a scope call with implementation design while the source finding classifies membership as registered hardening (`evidence/b12-note-003.md:136-149`, `:210-214`); and ITEM-B12-02's disposable witness proves the ED-43 drain mechanism, not the originally skipped "3 LIVE parked PEL intents drain after deploy" claim (`evidence/b12-note-001.md:13-20`, `:45-48`).

ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Prior alternative framing stands: split B12-01 into a scope-disposition artifact or an explicit new runtime-role requirement before implementation; re-anchor B12-02 as an ED-43 recovery/regression witness with one precise disposable PEL-drain arm, and keep any real-live-drain claim as a separate deploy checklist.
DONE=AMENDMENT-BATCH-B-B12-WRITECONSUMER-REVIEW-20260203

ED31_reprovision_review

2026-02-01T19:01Z · design/fix review · verdict: advisory

REVIEW: BLOCKED
- BLOCKING: `--reprovision` can still report success while reusing hand-state: `provision/wo-note-024.sh:583-612` converts catalog builder ingest failure into a warning and accepts any pre-existing catalog, while `provision/wo-note-024.sh:678-698` converts staged generation failure or an empty scaffold choice into a warning/skip. Ground truth already contains `catalogs/wo-note-025.yaml` and `git status --short -- tools/stocktrace/_staging/wo-note-026.yaml` reports `M`, so `wo-log-107.log` is not proof of fresh production. This violates WO §B8.4 AC-67/AC-77 and §B8.7.2.k AP-#56 fail-loud discipline. Minimum clearance: ratify fail-loud reprovision semantics and require external evidence that catalog and staging artifacts were freshly regenerated.
- BLOCKING: G2 guards preserve existing files but do not enforce the WO §B8.7.5 B7-production-tools invariant. `provision/wo-note-024.sh:376-417` recollects entity/write answers, `:480-560` can preserve the old profile while rotating its credential, and `:743-863` derives production filenames from the new answers and writes any absent files. A drifted heredoc can silently add production tools beside the proven B7 tools while runtime profile bytes remain old, contrary WO §B8.4 AC-77 "WITHOUT overwriting the proven B7 tools" and §B8.7.5. Minimum clearance: decide and enforce preserved-profile answer validation or derivation, plus fail on any production-tool-directory delta during reprovision.
- BLOCKING: G3 is not "already idempotent" or source-scoped. `provision/wo-note-024.sh:711-730` always writes `core:entity:stocktrace:product:1` and always sed-edits `tools/stocktrace/_staging/wo-note-026.yaml`, even during the partline run; this conflicts with the `{ns}:entity:{source}:{type}:{id}` source contract at `src/cache the mod module` and WO §B8.4 AC-78 per-source namespace isolation. The same sed also makes the on-disk `name: add_stock` differ from fresh generator output `name: Add Product` recorded at `tools/stocktrace/_staging/wo-note-026.yaml.dif:9-10`, so AC-77 fresh-diff cannot pass. Minimum clearance: ratify the source-scoped tail behavior and demonstrate namespace-correct two-source reprovision plus fresh-generate/diff/listed evidence.
DONE=ED31-REPROVISION-REVIEW-20260201

ED31_reprovision_REVISED_review

2026-02-01T19:29Z · design/fix review · verdict: advisory

REVIEW: BLOCKED
- BLOCKING: the revised `WRITE_ENABLED` derivation is not defined by committed profile ground truth. `profiles/wo-note-027.yaml:19-23,72-79` encodes read-only only in comments while preserving the schema-mandatory `operations.write_entity` placeholder; `src/the schema module` has no machine-readable disabled field. Therefore “derive from committed profile” cannot reliably produce partline=false versus stocktrace=true, and the proposed seed gate / step5 behavior can silently violate WO §B8.4 AC-78 per-Manifest independence. Minimum clearance: ratify a machine-readable derivation rule or profile signal and require an external witness that asserts stocktrace=true and partline=false from profile bytes before reprovision side effects.
- BLOCKING: the revised `SCAFFOLD_CMD from existing _staging basename` rule is undefined on the actual tree. Probe result: `tools/stocktrace/_staging/` contains 7 `*wo-note-028.yaml` basenames and `tools/partline/_staging/` contains 6; this contradicts the decision claim that partline has none. With empty scaffold now fatal and pre-delete scoped to `_staging/wo-note-029.yaml`, neither the partline full run nor the AC-77 `add_stock` freshness witness has a deterministic selected target. This leaves the prior hand-state blocker open under WO §B8.4 AC-67/AC-77 and §B8.7.2.b. Minimum clearance: ratify an explicit per-source scaffold-command source/selection rule and witness the exact pre-absent→post-present target for each reprovision run.
- BLOCKING: the proposed production-only sha256 gate excludes `_staging/`, but `_staging/` is runtime-visible in the close configuration: `deploy/wo-note-030.yaml:79-84` sets `CORE_COMMAND_INCLUDE_STAGING=true`, and `the registry module` loads every staged file. Exact pre-delete followed by ingest/generate failure can leave a mounted runtime command deleted, while unrelated staged hand-state remains outside the manifest gate and can still affect `registry/list`; this is not a fail-loud-but-state-preserving close for WO §B8.4 AC-68/AC-77/AC-78. Minimum clearance: decide and evidence rollback or atomic replacement on regeneration failure, and externally gate the runtime-visible staged surface (or isolate staging enablement to the controlled AC-77 witness).
DONE=ED31-REPROVISION-REVISED-REVIEW-20260201

ED31_v3_review

2026-02-01T20:00Z · design/fix review · verdict: advisory

REVIEW: BLOCKED
- BLOCKING: v3 says “regenerate catalog → scratch” but does not bind that step to the actual catalog builder CLI or service instance filesystem. `provision/wo-note-024.sh:583-590` still invokes the legacy `catalog builder ingest "${SOURCE_NAME}"` and masks non-zero; `catalog builder/the main module,141-165` requires `--source`, `--kind`, `--pass a`, and `--out`; `deploy/wo-note-030.yaml:133-143` mounts `/catalogs` but neither the tracked per-source sources nor a scratch output path. Without an explicit per-source source/kind mapping, service instance-visible scratch mount, and fail-loud schema-valid postcondition, stale ignored `catalogs/*.yaml` can remain the apparent success path, contrary WO §B8.4 AC-67 and AC-74/AC-78(a). Minimum clearance: encode the two source/kind invocations and prove each this-run scratch catalog by absent-before → generated → schema-valid evidence.
- BLOCKING: the proposed HAS_WRITE command is described as deriving from committed bytes but `grep -lE '^class: write' tools/<source>/*wo-note-028.yaml` reads mutable working-tree bytes. Current probe is clean for production files and returns stocktrace=true / partline=false, but v3 removed the manifest gate and does not require a close-run clean check or `HEAD` read before using the result to decide cache store side effects. A dirty production tool can silently flip seed/no-seed behavior and still satisfy the witness against the same hand-state, violating WO §B8.4 AC-78 per-Manifest independence. Minimum clearance: derive from committed `HEAD` bytes or fail-loud unless the non-recursive production tool set is git-clean, then externally assert both values before side effects.
- BLOCKING: v3 retains a destructive cache store gap: backup-first followed by `DEL` + `STORE-SET` is not state-preserving when replacement fails. WO §B8.7.2.e makes `${NS}:entity:stocktrace:product:1` a required JSON document for AC-70/71; after a successful `DEL`, a failed `STORE-SET` leaves that live fixture absent even though reprovision fails. Minimum clearance: ratify rollback/atomic-replacement semantics and add an external failure-path witness proving the prior key is restored unchanged when replacement fails.
DONE=ED31-V3-REVIEW-20260201

adversarial_strategy_review

2026-02-02T01:19Z · design/fix review · verdict: advisory

BOTTOM_LINE: reconsider-approach

- HOLE 1 - "Governed" currently means that the write bracket runs, not that an authored governance policy exists. `wo-note-031.md:5,38,56` claims every mutation passes a developer-authored governance gate and that governance definitions are required. The runtime instead silently substitutes `GovernanceDefinition::proceed_default()` when a tool has no governance definition (`src/the mod module`), and that default explicitly proceeds with no checks (`the registry module`). That is a useful substrate fallback during development, but it is not an enforceable product guarantee. Alternative framing: separate the invariant "every write enters the bracket" from the admission policy "every production write tool has a validated policy." Fail closed at registration or startup for production write tools missing governance artifacts; if an unconditional allow policy is needed, require an explicit reviewed declaration rather than a silent default.

- HOLE 2 - cache store estate isolation does not establish runtime tool-surface isolation. `wo-note-031.md:5,58` treats per-source namespacing as sufficient for N-source composition, but the registry keys tools, governance definitions, and source routing by plain tool name (`the registry module`). Loading a second source with the same ordinary command name silently overwrites the first tool and its route (`the registry module,434-460`), and runtime dispatch resolves that plain name (`src/the mod module`). Alternative framing: make `(SourceId, command_name)` the canonical identity everywhere, expose stable qualified names such as `source.tool`, permit unqualified aliases only when globally unique, and fail fast on collisions.

- HOLE 3 - The dev-zone containment claim and the future secure AI-authoring claim cross a trust boundary that is not structurally enforced. `wo-note-031.md:31,52,59` says hooks are contained and cache-only through context, but `CommandContext` exposes the full cache store layer (`the command_context module`), including mutation methods (`src/cache the entities module,83`). The generator produces declarative YAML (`catalog builder/the generator module,96-129`), while executable compiled-service handlers remain compiled, trusted code wired through the inventory (`src/the mod module`). Alternative framing: define two tiers. Keep native hooks as reviewed privileged extensions with an explicit promotion step. For future AI-authored behavior, use a declarative DSL or capability-limited sandbox that receives read-only estate views and emits narrow write intents for the bracket; do not describe arbitrary in-process hooks as contained.

DONE=ADVERSARIAL-STRATEGY-REVIEW-20260202

ac111_deep_dive_review

2026-02-02T03:38Z · design/fix review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- The cache store full-reconcile path can evict valid cached entities when its read budget runs out mid-enumeration. `the sync module` breaks out and returns a partial `source_ids` set, then `the sync module` treats every cached ID absent from that partial set as a phantom and deletes it. The comment says partial enumeration may merely miss evictions, but the implemented direction is destructive false eviction. This violates the INV-9 estate contract and undermines the cache-only read source of truth (§B8 AC-75 / WO `the work-order close bar`). This is not a documentation nit: a sufficiently large source or depleted budget can corrupt the mirrored estate.
- The ingestion capability proof does not prove trustworthy failure-shape capture. `catalog builder/the pass_b module` records any probe labeled `negative` as an error envelope without verifying HTTP status or error semantics. The durable AC-110 evidence admits the negative inventory probe returned HTTP 200 with an ordinary item and then persisted that item as a `not_found` failure shape (`evidence/wo-log-038.log`, Sections 4-5). The same evidence says write/action probes were skipped, while AC-110 requires success+error response shapes per command (WO `the work-order close bar`). The current pipeline can emit schema-valid but semantically false manifests.
- The sideload deployment claim is not yet stack-wide or repeatable. `provision/secrets service/service-stackfile.release:41-44` still copies the secrets service binary into `source-secrets service:release`, while amended AC-94/W4 requires generic-substrate images with no app binary baked (`the work-order close bar,3777`). The re-verification checked the runtime image only (`evidence/b10-note-004.md:65-68`). Separately, retained-volume re-up is internally inconsistent: `deploy/wo-note-032.sh:291-295` generates fresh cache store and runtime secrets, `:343-354` skips broker updates when old records exist, and `:377-385` prints the newly generated bearer rather than the stored bearer. After `down` without `--purge`, the advertised repeatable path can hand the operator an unusable token and split cache store from the broker-resolved password.

ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Treat source enumeration as an all-or-nothing snapshot for phantom eviction: return `Complete(set)` or `Incomplete`, and skip deletion on `Incomplete`. Resume later or budget full reconcile separately.
- Treat Pass B as an observation validator, not a capture copier: require expected status-class/error-shape predicates for negative probes, record mismatches as failed proof, and distinguish `documented`, `probe_validated`, and `unproven` per call.
- Define deploy close as stack-wide substrate inspection plus two lifecycle probes: fresh `up`, and retained-state `down` → `up`. Either fetch/reuse persisted broker secrets or rotate broker records and dependent services atomically; never print a token that was not stored.

DONE=AC111-DEEP-DIVE-REVIEW-20260202

AC110_unproven_schema_mechanism_proposal_review

2026-02-02T05:16Z · design/fix review · verdict: reconsider-approach

BOTTOM-LINE: reconsider-approach

HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- A status-only split (`2xx` = unproven, non-`2xx` = proven failure) repeats the class of semantic shortcut AC-110 is supposed to remove. The locked source contract supports `body_field` success signals and explicitly requires HTTP-200-with-body-error classification (`the work-order close bar`, `the work-order close bar`, `src/source the classify module`, `src/source the classify module`). A negative probe returning `200` with a body-declared error is a proven failure shape, not necessarily unproven. Route probe outcomes through the same success-signal semantics as the runtime, or persist the observation without claiming a verdict until that predicate can be evaluated. Add the existing AC-80 HTTP-200-with-body-error axis to the close-bar.
- A dedicated `unproven_shapes[]` exception list is too narrow to represent failed proof attempts truthfully. Pass B already records transport failures as `http_status: 0` plus a network-error envelope (`catalog builder/the pass_b module`), and the current non-`2xx` collector can turn a negative transport failure into a fabricated source `failure_shape` (`catalog builder/the pass_b module`). Positive probes that return errors also fail to prove success but receive no manifest-level unproven record (`catalog builder/the pass_b module`). AC-110 requires a truthful proof distinction for probe-safe calls (`the work-order close bar`), not only a marker for one trigger. Prefer a general probe-evidence section keyed by call and probe, with an explicit outcome such as `validated|unproven`, a reason such as `accepted_bad_input|transport_error|unexpected_error|semantic_predicate_unavailable`, optional HTTP status, and captured observation. Derive `failure_shapes[]` only from observations proven to be source failures.
- Extending the language-neutral portability contract without extending its semantic validator leaves the new signal structurally valid but untrustworthy. `validate_catalog` runs the schema pass and VR-1..12 (`tools/source_ref_validator/the lib module`); those checks currently validate existing reference edges but have no rule for a new evidence section (`tools/source_ref_validator/the semantic module`). Since the per-call view depends on grouping by `call_id`, a stale or misspelled `call_id` must not validate. Add a semantic rule requiring every evidence `call_id` to resolve to `calls[*].id`, require a non-empty `probe_id`, constrain HTTP status when present, and reject outcome/reason combinations that contradict each other.

ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Keep `failure_shapes[]` as the derived, generator-facing set of proven source failures. Add an optional top-level `probe_evidence[]` audit section for all Pass-B proof attempts, with trigger-granular outcome and reason fields. Evaluate success with the canonical success-signal semantics, treat transport failures as unproven observations, add validator referential checks, and prove both the original accepted-bad-input case and the existing AC-80 body-error case.

DONE=AC110-UNPROVEN-SCHEMA-MECHANISM-PROPOSAL-REVIEW-20260202

AC110_revised_probe_evidence_review

2026-02-02T05:37Z · design/fix review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- "`Reuse the classify module::is_success_signal`" is not yet an implementable build-time portability mechanism. The runtime helper is private, binary-valued, and consumes typed profile `ErrorSemantics` (`src/source the classify module`, `src/the schema module`); the separate catalog builder crate does not depend on the runtime crate (`catalog builder/the build tool.toml`). The manifest carries only a free-form hint string such as `http_2xx` or `body.result.state==ok` (`schema/wo-note-034.yaml:202-210`), and Pass A currently defaults it to `http_2xx` (`catalog builder/the pass_a module`). Worse, the runtime helper treats an absent body field as success (`src/source the classify module`), so it cannot produce the proposed `semantic_predicate_unavailable` state. Define a language-neutral structured success predicate and a build-time tri-state evaluator (`success|failure|unavailable`) aligned with runtime semantics. Also amend the authoritative AC-110 wording: WO §B12 still says any negative READ probe returning `2xx` becomes `unproven` (`the work-order close bar`), which conflicts with the revised AC-80 body-error case.
- `probe_evidence[]` still collapses distinct axes and drops the probe intent required to interpret an audit record. The probe grammar requires `kind ∈ {positive,negative}` plus expected status class (`tools/source_ref_validator/schema/wo-note-035.yaml:32-45`), the current observation model preserves `kind` (`catalog builder/the pass_b module`), and enrichment uses it both to derive failure shapes and to raise positive-call provenance (`catalog builder/the pass_b module`). An evidence row containing only `outcome ∈ {validated,unproven}` cannot distinguish a validated positive success from a validated negative failure, and the proposed reason enum has no explicit successful or expected-failure case. Preserve `probe_kind`, separate `observed_result` (`source_success|source_failure|transport_failure|predicate_unavailable`) from `proof_status` (`validated|unproven`), and retain `trigger_kind` for negative attempts. Derive `failure_shapes[]` only from `negative + source_failure + validated`; raise call provenance only from `positive + source_success + validated`.
- VR-13 needs a cross-section and rerun invariant, not only entry-local checks. Today Pass B overwrites `failure_shapes` only when the newly collected vector is non-empty (`catalog builder/the pass_b module`), while the generator consumes whatever shapes remain in the manifest (`catalog builder/the generator module`, `catalog builder/the generator module`). A rerun with no proven failures can therefore preserve stale or previously fabricated shapes and still emit governance classifications. Make each Pass-B output a deterministic evidence snapshot: always replace or remove prior `probe_evidence` and derived `failure_shapes`, even when empty. Extend validation so each failure shape has exactly one matching current evidence row by `{call_id,probe_id,http_status}`, that row is `negative + source_failure + validated`, and evidence keys are unique.

ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Keep the revised optional top-level audit section, but define it as a normalized evidence ledger rather than a two-state exception list: structured success predicate → tri-state build-time evaluation → explicit evidence row with probe intent, observed result, and proof status → deterministically rebuilt `failure_shapes[]` projection. Validate both the ledger itself and the projection relationship, then word the WO close-bar in predicate terms: accepted bad input is unproven only when the success predicate says success; an AC-80 `200` body-error is a proven failure when the predicate says failure.

DONE=AC110-REVISED-PROBE-EVIDENCE-REVIEW-20260202

AC115_failclosed_evict_proposal_review

2026-02-02T05:57Z · design/fix review · verdict: reconsider-approach

BOTTOM-LINE: reconsider-approach

HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- The proposal preserves a claim contract that does not actually serialize inbound event feed eviction against the sync worker, despite AC-115 explicitly requiring serialization vs sync worker via the claim (`the work-order close bar`). The inbound event feed acquires `{ns}:claim:{type}:{id}` (`src/the inbound event feed_ingest module`, `src/cache the coordination module`), but sync worker mutates entities directly in all three paths without acquiring that claim (`the sync module`, `the sync module`, `the sync module`). A concrete race remains: inbound event feed reads stored `T1`, decides incoming out-of-set `T2` is safe to evict, sync worker concurrently upserts newer `T3`, then inbound event feed deletes `T3`. Make sync worker participate in the per-entity claim zone for every upsert/evict, or replace the delete with an atomic compare-and-delete against the observed record freshness and explicitly amend the AC framing.
- The proposed asymmetric policy still violates the pre-existing AC-51 monotonic corpus-write contract: inbound event feed writes apply only when incoming freshness is `>=` stored freshness (`the work-order close bar`, `the work-order close bar`). `upsert_entity` is a full `STORE-SET` overwrite (`src/cache the entities module`), so an upsert is not harmless merely because it is not a delete. Allowing an in-collection inbound event feed upsert after `get_entity -> Err` or `Ok(Some)` with unparseable stored timestamp can overwrite a newer record whose freshness could not be established. Use one mutation-safety determination: allow first-write hydration only on positively established `Ok(None)`; allow replacement or eviction only on `Ok(Some)` plus a parsed timestamp proving incoming is current; suppress and warn on indeterminate stored state.
- The proposed witness recipe is grounded in a false reachability premise and leaves an externally inducible branch untested. RFC 3339 watermark strings are already parsed by `extract_stored_ts` (`src/the inbound event feed_ingest module`), so a valid ISO-string sync worker-shaped seed will not exercise `Indeterminate`. Conversely, `get_entity -> Err` is externally inducible without an in-binary seam: seed a schema-invalid cached JSON document so deserialization fails loudly (`src/cache the entities module`), then send the signed inbound event feed and observe via `cachectl` that the document survives. Exercise separate witnesses for RFC-3339 stale suppression, missing/unparseable watermark suppression, malformed-corpus read-error suppression, current eviction, and first-write hydration.

ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Frame this as a claim-held, fail-closed inbound event feed mutation bracket rather than an eviction-only exception. Read stored state once under a coordination mechanism shared with sync worker; classify it as `Absent | IncomingCurrent | StoredNewer | Indeterminate`; permit first-write upsert only for `Absent`, permit upsert or evict only for `IncomingCurrent`, and suppress with an observable warning for `StoredNewer` or `Indeterminate`. Prove the full branch matrix externally against the production route and cache store corpus.

DONE=AC115-FAILCLOSED-EVICT-PROPOSAL-REVIEW-20260202

AC69_structural_vs_witness_review

2026-02-02T16:32Z · design/fix review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes
HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- AC-69 requires the runtime witness. WO §B8.4 AC-69 (`the work-order close bar`) does not ask only whether INV-1 is structurally encoded; it names the close-bar observations: `{ns}:budget:read` unchanged and `0 source adapter calls` on the Bearer→runtime READ. The current artifacts (`evidence/wo-record-055.json`, `evidence/cache wo-log-160.log`) demonstrate cache-served output and cache presence, but do not capture either named zero-source observation. AP-#56 is binding external-verification discipline (`the work-order close bar`), so a code-path argument cannot replace the omitted runtime evidence.
- The construction proof is sound but supporting, not substitutive. `the platform/src/the read module` gives `ReadEngine` only cache store/profile resources and `:99-100` queries cache store; `the platform/the sync module`, `:303`, and `:346` place `read_budget.try_acquire` in sync worker paths. That establishes the intended architecture. It does not show that the deployed runtime under review matches the inspected source or that the actual AC-69 call window had no source adapter activity.
- AC-71 is not a sound waiver precedent. WO §B8.4 AC-71 (`the work-order close bar`) independently names `no PUT fired (cache unchanged)`. Reusing a structural-only treatment for another explicitly observable clause compounds witness debt; it does not relax AC-69's verbatim close-bar.
ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Record consensus as: INV-1 structural proof accepted as the design argument; AC-69 closure still requires a small AP-#56 external supplement. Capture `{ns}:budget:read` before and after one Bearer→runtime READ with `cachectl`, plus an externally read source adapter-call count for the bounded call window from existing logs. Do not add in-process counters, endpoints, or test branches. Treat an AC-71 before/after cache snapshot as a separate consistency cleanup, not as a reason to waive AC-69.
DONE=AC69-STRUCTURAL-VS-WITNESS-REVIEW-20260202

AC115_claim_bracket_review

2026-02-02T17:02Z · design/fix review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- The proposed bounded-watermark recovery is not representable safely against the current generic source adapter contract. `list_changed_impl` forwards only an opaque integer `since` value (`src/source the read_ops module`), and `OpDef` carries only `since_param` with no inclusive/exclusive boundary semantics (`src/the schema module`). A claim-busy entity can share a second-granularity timestamp with the old watermark or with already-processed entities; there may be no monotone, source-derived value "strictly below" the deferred timestamp. Advancing to a fabricated `earliest_deferred_ts - 1` also conflicts with AC-30's watermark-to-max-source-ts contract (`the work-order close bar`). Treat any claim-busy delta item as an incomplete cycle and leave the watermark unchanged, matching the existing full-success-only discipline (`the sync module`), or introduce an explicit durable deferred-item mechanism with a separately specified recovery contract.
- The load-bearing runtime witness can pass without proving the new behavior. Holding a claim as a the stand-in reviewer writer exercises the inbound event feed's already-existing `acquire_claim` and claim-busy skip (`src/the inbound event feed_ingest module`); it does not prove that the sync worker now participates at each mutation site, which is the missing half required by AC-115's "serialized vs sync worker via the claim" clause (`the work-order close bar`; current mutation sites `the sync module`, `:277-282`, `:356-362`). The concurrency close-bar must stage a real sync worker cycle against a inbound event feed, externally observe contention, and prove post-release recovery. Also describe the inbound event feed behavior accurately: it skips rather than blocks when the claim is busy.
- Part A creates a new frequent owner of the per-entity claim but only specifies recovery when sync worker loses contention. In the opposite direction, the inbound event feed currently acknowledges claim-busy contention with a silent successful skip (`src/the inbound event feed_ingest module`). Once sync worker claims every mutation, a current inbound event feed can be dropped while sync worker commits an older fetched snapshot. That is not enough for the peer hydration route or its corpus-hydration witness (`the work-order close bar`, `:2021`) unless recovery from the authoritative source is guaranteed and proven for every inbound event feed-capable profile. Define symmetric recovery: bounded retry plus a retryable response, or durable event deferral; then witness the sync worker-wins case externally.

ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Keep the two-part direction and classify it as `harmonize`, not `negate`: the per-entity claim is orthogonal to the INV-9 singleton lease and fulfills the existing B5/AC-115 serialization intent. Shape Part A as a symmetric contention protocol: unique sync worker holder, claim around every mutation, delta-cycle watermark unchanged on any claim-busy skip unless a durable deferred queue is added, and an explicit recovery rule for inbound event feed-busy skips. Shape Part B as the proposed claim-held `Absent | IncomingCurrent | StoredNewer | Indeterminate` bracket on both mutations. Close at `concurrency` tier with a real sync worker-versus-inbound event feed staged race, next-tick replay proof, inbound event feed-busy recovery proof, and the four-state external corpus matrix.

DONE=AC115-CLAIM-BRACKET-REVIEW-20260202

FOLD5_AC110_closebar_harmonize_review

2026-02-02T17:29Z · design/fix review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3, highest severity first; each cites a WO §/AC, a source path:line, or an evidence path/probe — not the proposal's own internal logic):
- This is a HARMONIZE, not a NEGATE: the locked AC-110 row already makes semantic truthfulness the governing requirement (`the work-order close bar`), AC-80 requires body-aware handling of HTTP-200-with-body-error (`the work-order close bar`), and ED-37 ratifies the predicate reading while explicitly parking the flat-wording correction for a WO amendment (`wo-note-036.md:624`). The proposed landing metadata nevertheless says `superseded_ed: ED-37` (`scoping/wo-note-037.md:6,38`). That provenance is backwards: ED-37 is the authority this amendment implements, not a decision being superseded. Supersede the stale AC-110 illustration only; cite ED-37 as the grounding/implementing ED.
- The authoritative wording should not collapse an unevaluable predicate and an invalid predicate into the same accepted close state. An absent body field is truthfully recorded as `predicate_unavailable → unproven` by the tri-state evaluator (`tools/source_ref_validator/the probe_evidence module`). A malformed `success_signal`, however, is also rejected by VR-13 (`tools/source_ref_validator/the semantic module`), and Pass B rejects an enriched manifest that fails validation (`catalog builder/the pass_b module`). The proposed close-bar groups “absent body field / malformed hint” together as merely `unproven` (`scoping/wo-note-037.md:30`). Preserve the distinction so the WO text does not imply that a malformed portability contract may close successfully.

ALTERNATIVE FRAMING (how you would shape it differently — offer one whenever you have it):
- Land an append-superseding AC-110 clarification grounded in ED-37: proof is decided by the body-aware success predicate, not status alone; `negative + source_success`, transport failure, positive error, and an unevaluable response field are recorded `unproven`; `negative + source_failure` is a proven `failure_shape`, including AC-80 HTTP-200 body-errors; malformed predicate configuration is rejected by VR-13. Mark the stale flat AC-110 illustration as superseded and retain ED-37 as the ratified authority.

DONE=FOLD5-AC110-CLOSEBAR-HARMONIZE-REVIEW-20260202

AC111_deep_dive_refresh_review

2026-02-02T18:34Z · design/fix review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest three):
- The governance-module framing overstates enforced containment. `the command_context module` gives every developer hook the full `Arc<cache storeLayer>`, while `src/cache the entities module` and `src/cache the entities module` expose public upsert and evict operations. A hook can therefore mutate cache store estate directly, including outside the bracketed target mutation. The built state is "trusted cache store-capable extension code with no direct source adapter handle," not "cache-only access that cannot corrupt generic core or INV-1..10."
- The source-integration picture omits a material multi-source limit. Runtime mounting scans profiles with `find_map` and mounts only the first inbound event feed configuration; the source explicitly calls multi-source inbound event feed dispatch a future refinement (`the main module`). Because the backing profile map is not an ordered routing table, the document should not imply that every attached source can independently participate in inbound event feed ingest today.
- The [§B12] cache store recovery summary is broader than the landed guarantees. Delta-cycle contention freezes the watermark and replays on the next tick (`the sync module`), but phantom-evict contention only skips until a later full reconcile (`the sync module`), and full-pass contention is revisited by a later full pass rather than guaranteed by the next delta tick (`the sync module`). Separately, inbound event feed ingest maps every cached-record read error to 503 retry, although the branch does not distinguish transient failure from persistent corpus corruption (`src/the inbound event feed_ingest module`). Describe those recovery intervals and operational-repair cases explicitly rather than calling recovery uniformly symmetric.

ALTERNATIVE FRAMING (operator-facing):
- Keep the by-module deep dive, but split each capability into `ENFORCED NOW`, `TRUSTED EXTENSION BOUNDARY`, and `DEFERRED LIMIT`. Put hook mutation power in the trusted boundary; put one-inbound event feed-profile-per-server in deferred limits; and describe cache store recovery per mutation path: next delta tick, next scheduled full reconcile, or operator repair for persistent cached-record corruption. This preserves the real §B12 gains without turning implementation intent into a stronger runtime contract.

DONE=AC111-DEEP-DIVE-REFRESH-REVIEW-20260202

CF_AC100_closebar_harmonize_review

2026-02-02T19:14Z · design/fix review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3):
- This is a HARMONIZE, not a NEGATE: the locked AC-100 wording (`the work-order close bar`) conflicts with the operator-ratified ED-33 acceptance of in-process compiled-service hooks with full estate access (`wo-note-036.md:488`). However, the superseding text still overstates enforcement when it says a hook cannot reach upstream sources. `CommandHook` receives no injected source adapter (`the command_context module`), but it is compiled in-process compiled-service and the crate already depends on `reqwest` (`the build tool.toml:23`). Absence of an injected source adapter handle is a normal-path DI property, not a capability sandbox or a structural prohibition on outbound code.
- The replacement also carries forward an unenforced INV-1..10 guarantee. `CommandContext::cache store()` returns the full `Arc<cache storeLayer>` (`the command_context module`); that surface publicly exposes estate mutation (`src/cache the entities module,82-89`), watermark mutation (`src/cache the coordination module`), and write-stream injection/status operations (`src/cache the stream module,212-248`). A buggy trusted hook can bypass the normal bracket and damage invariant-bearing state. The accurate claim is that the generic framework path retains its bracket discipline; arbitrary in-process extension code is trusted and reviewed, not prevented from violating it.
- Keep the amendment scoped to containment wording; do not let it imply that the separate AC-100 one-command authoring bar is already reconciled. The scaffold command emits CommandSpec and GovernanceDef YAML only (`catalog builder/the generator module,30-33`), while hook activation still requires authoring compiled-service plus manually adding module and inventory entries (`src/the mod module`; `docs/wo-note-038.md:277-341`). The existing auto-wire witness proves startup consumes a static inventory without editing `the main module` (`evidence/wo-log-030.log:1-17`); it does not prove the WO's stronger "one command yields ... hook AUTO-registered" clause (`the work-order close bar`).

ALTERNATIVE FRAMING (how to shape it differently):
- Append-supersede only the containment clause with a narrow statement: `CommandHook` is a TRUSTED IN-PROCESS EXTENSION BOUNDARY, not a security boundary; the standard DI path injects cache store context and no source adapter handle; framework-owned calls preserve the write-governance layer bracket, while extension safety depends on reviewed code. Track the orthogonal AC-100 authoring question separately: either externally prove a command that emits/registers the hook scaffold, or explicitly harmonize that acceptance clause under operator authority rather than treating static inventory consumption as equivalent.

DONE=CF-AC100-CLOSEBAR-HARMONIZE-REVIEW-20260202

ac113_src_layout_proposal_review

2026-02-02T19:47Z · design/fix review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3):
- Approach unchanged since the prior one-pass AC-113 review; prior holes stand/dispositioned. The appended the stand-in reviewer commentary does not materially change the move-vs-stay shape grounded in WO §B11 AC-113 (`the work-order close bar,3834`). No fresh review loop.

ALTERNATIVE FRAMING (how to shape it differently):
- Prior alternative framing stands: treat AC-113 as a path-contract migration with an explicit product-source ownership map, a separately named runtime-asset surface, declared deploy/provision/test-harness exceptions, proof updates before moves, and clean-build plus AC-94/95 sideload re-witness after the move.

DONE=AC113-SRC-LAYOUT-PROPOSAL-REVIEW-20260202

CF_EVENTFEED_MULTI_design_proposal_review

2026-02-02T21:51Z · design/fix review · verdict: proceed

BOTTOM-LINE: proceed

HOLES (strongest objections to the APPROACH; max 3):
- Approach unchanged — prior holes stand/dispositioned. the adjudicator task #92 verifies the ED-42 implementation diff conforms to Shape 1 + folds F-1..F-7, including exact per-source cache store binding, suffix validation, and the two banked transparency statements. Its live boot transcript corroborates mount-all, audited degraded mounts, duplicate-suffix abort, and reserved-suffix abort. No fresh approach hole and no further the adversarial reviewer cycle.

ALTERNATIVE FRAMING (how you would shape it differently):
- Keep the ratified suffix-distinguished mounting shape and proceed to the external runtime witness: cross-isolation, cross-auth-401 for distinct-secret pairs, degraded-mode audit, collision and reserved-suffix controls, plus stale and claim-busy handling on every route.

DONE=CF-EVENTFEED-MULTI-DESIGN-PROPOSAL-REVIEW-20260202

AC95_launcher_reuse_fix_proposal_review

2026-02-02T22:17Z · design/fix review · verdict: proceed

BOTTOM-LINE: proceed

HOLES (strongest objections to the APPROACH; max 3):
- Approach unchanged — prior holes stand/dispositioned. ED-41 REVISION-4 accepts the comprehensive pre-mutation classifier, and the adjudicator task #108 verifies the #106 diff implements it: keygen is behind classification, `CLEAN_EMPTY` requires no key/records/archives/provisioning creds, inconsistent states abort zero-mutation, recovery never touches source credentials, and the #94 classification-gates-reuse fix is preserved. No fresh the adversarial reviewer review loop.

ALTERNATIVE FRAMING (how you would shape it differently):
- Prior alternative framing is now the ratified and verified shape. Proceed with the definitive third security-tier witness using REVISION-3/4 arms: fetchable corrupt metadata aborts, key-loss and orphaned archive/prov-cred states abort, recovery never replaces an existing key, and only `CLEAN_EMPTY` performs first-up provisioning.

DONE=AC95-LAUNCHER-REUSE-FIX-PROPOSAL-REVIEW-20260202

secrets_service_failclosed_fix_proposal_review

2026-02-02T22:42Z · design/fix review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES (strongest objections to the APPROACH; max 3):
- The proposed discriminator is only as good as the provenance you keep, and the current load path throws that provenance away. `the main module` collapses both missing and corrupt `.meta` into `allowed_roles: None`, so the later `stored_on_disk == true && allowed_roles == None` check in `the store module` is inferring corruption after the fact rather than proving it. That works for the current bug, but it is brittle if a legacy or alternate persistent format ever produces a meta-less entry for a reason other than corruption. The safer shape is to keep an explicit ACL state at load time and make the loader decide whether the secret is admissible, rather than recovering intent from a bool+Option pair later.
- `FetchResult::MetadataUnavailable` is an attractive diagnostic, but it weakens the credential plane if it leaks that a secret exists-but-is-broken. The current `NotFound`/`RoleNotAuthorized` split already gives the caller enough information to act, and AP-#19 only requires fail-closed, not a new distinguishable denial class. For a broker, “corrupt metadata” is usually better handled as a loud operator log plus an existence-hiding client response, not as a third externally visible failure mode.
- The load-time part is too soft for a security-plane defect if it only logs and keeps serving. If the `.meta` is required for every persistent secret, then the fail-closed point belongs at load: refuse to materialize the secret into the in-memory store, or quarantine it in a separate broken-entry bucket that cannot be fetched by any role. That keeps the runtime surface honest and avoids having fetch-time logic carry a security invariant that the loader already knows is violated.

ALTERNATIVE FRAMING (how I would shape it differently):
- Make the persistent-secret state explicit in the in-memory model: something like `EntrySource::{PersistentWithAcl, PersistentAclMissing, Ephemeral}` or a dedicated `acl_state` enum. Then the loader can fail loud on `PersistentAclMissing`, while fetch remains a simple authorization check over already-validated entries.
- Keep the external denial response conservative. Log the corruption loudly at startup, but map client-visible fetch failures to the existing `NotFound` or `RoleNotAuthorized` surface so the broker does not become an oracle for secret presence or corruption state.
- If you want defense in depth, keep it in that order: loader rejects or quarantines bad persistent entries first, fetch path rechecks only as a guardrail, and the client response stays indistinguishable from other denials.
DONE=SECRETS-SERVICE-FAILCLOSED-FIX-PROPOSAL-REVIEW-20260202

adversarial_metrics_plan_review

2026-02-03T19:29Z · design/fix review · verdict: proceed-with-changes

BOTTOM-LINE: proceed-with-changes

HOLES:
- The mutation-terminal seam is not sufficient for the proposed `(source, tool, class, terminal)` labels or ROI. `publish_verdict` only receives `WriteVerdict`, and `WriteVerdict` only carries `correlation_id` + `outcome` (`the domain module`; `src/cache the stream module`). The dims are available one layer earlier in `write consumer`: `intent.command_name`, `registry.get_source`, `spec`, and `gd` are in scope before the final publish (`src/the mod module`, `:389-418`). Some early rejection branches publish before the source/governance context is complete (`src/the mod module`). So the keystone is directionally right for tool calls, but false at the proposed publish hook unless the verdict is enriched or instrumentation moves up to the consumer.
- `reject_reason` is the wrong label shape. It is free-form config text (`GovCheck.reject_reason`, `the registry module`) and is surfaced verbatim by `first_failing_check` (`the registry module`) into `Rejected { reason }` (`src/writer/the write-governance module:161-165`). Other paths also put arbitrary strings into the same terminal class, including hooks (`src/writer/the write-governance module:171-179`), replay exhaustion (`src/writer/the write-governance module:239-244`), source business rejects (`src/writer/the write-governance module:302-306`), and auth/internal errors (`src/writer/the write-governance module:312-356`). That creates cardinality and disclosure risk on an unauthenticated `/metrics` surface, and it still does not cleanly distinguish governance deny vs hook deny vs upstream/source reject.
- The off-hot-path claim mixes two different activities. Atomic `metrics::counter!` increments are plausible for tool/mutation counters, but the plan also proposes estate counts via `all_entity_ids`, which is an async cache store SCAN cursor loop (`src/cache the entities module`), and "durable I/O-schema'd logging" of what each tool did. Those are not atomic counter increments. If attached to request hooks or scrape-time handlers, they can put cache store I/O, allocation, or log writes back onto paths the plan says must stay off-hot-path.

ALTERNATIVE FRAMING:
- Make `dispatch_call` the request-attempt hook, and make `write consumer` the mutation-outcome hook. Capture bounded dimensions there while `intent`, `source`, `spec.class`, `gd`, and `outcome` are all in scope. Treat `publish_verdict` as transport plumbing, not the semantic metrics seam.
- Replace `reject_reason` with bounded labels such as `terminal`, `error_class`, and `decision_source={governance_check,command_hook,upstream_source,internal,auth,replay_exhausted}` plus an optional static `reason_code` authored in governance YAML. Keep human-readable reason text in logs/traces, not Prometheus labels.
- Split fast counters from background samplers. Inline hooks only increment counters/histograms from already-owned values. Estate counts, cache store scans, durable mutation audit rows, and ROI materialization should run in a periodic/background collector or append-only audit path with explicit backpressure and scrape-safe caching.

DONE=ADVERSARIAL-METRICS-PLAN-REVIEW-20260203

The false-success bootstrap run

evidence/b8-log-030.log · 2026-02-02T21:07Z · excerpt, reconstructed

The run the external gatekeeper round 4 caught: Step 4 logs 'Skipping catalog builder ingest — Pass-A deferred', yet the terminal prints '=== Source Onboarding COMPLETE ===' and exits 0. The same run generated a write op (PUT) for a read-only source spec.

── reconstructed excerpt · transposed from the real record ──

[provision] === Step 4: Catalog-builder ingest — Pass-A (catalog production) ===
[provision] WARNING: catalog-builder binary not found at the expected build path
[provision]   Build it first with a release build
[provision]   Skipping catalog-builder ingest — Pass-A deferred
[provision]
[provision] === Step 5: Command definitions + policy definitions ===
[provision] WRITE commands authored: update_stock.command.yaml + .policy.yaml
[provision] READ commands authored: list_stock.command.yaml + get_stock.command.yaml + policy files
[provision] Commands directory: <staging-area>/commands/stocktrace_ob/
[provision]
[provision] Restarting the runtime instance to reload the command registry...
 runtime instance  Restarting
 runtime instance  Started
[provision] Runtime restarted and healthy — new commands loaded
[provision]
[provision] Step 5 COMPLETE — command definitions authored + runtime restarted
[provision]
[provision] === Source Onboarding COMPLETE ===
[provision] Source 'stocktrace_ob' (seed shape) is onboarded.
[exit 0]

── what the gate saw ──
Step 4 logs the skip. Step 5 authors files and restarts. The terminal prints COMPLETE
and exits 0. Nothing in the chain verified ingest, activation, or serving.

The same run, pointed at the read-only source 'partline_ob' (input: write_path: none;
log line: "no MUTATE command authored"), still emitted this into the generated profile:

  operations.write_entity: UPDATE /parts/{id}

A read-only source, granted a write operation by generation. This file is the round-4 catch.

ED-46 Step-4 ingest + 3-layer loaded gate

evidence/b8-log-026.log · 2026-02-03T01:11Z · excerpt, reconstructed

The repaired path: real resolved-triple ingest, --activate force-recreate, and the 3-layer loaded/serving gate (registry/list registration + IDX-LIST/IDX-INFO per-source index + a serving registry/dispatch).

── reconstructed excerpt · transposed from the real record ──

# ED-46 Step-4 ingest + 3-layer loaded gate — repaired-path witness

[provision] === Step 4: Catalog-builder ingest — resolved-triple (kind/source/out) ===
[provision] ingest --kind seed   → stocktrace_ob catalog: 7 calls, validator OK
[provision] ingest --kind spec   → partline_ob catalog: 98 calls, validator OK
[provision] === Step 6: Activation — force-recreate (restart is NOT recreate) ===
[provision] === Step 7: 3-layer loaded/serving gate ===
[gate] L1 registration : registry/list contains stocktrace_ob.*      ✓
[gate] L2 index        : IDX-LIST shows {ns}:idx:stocktrace_ob:stock ✓
[gate] L3 serving      : registry/dispatch get_stock served          ✓
[provision] Activation VERIFIED — source is ONBOARDED

── why L2 uses IDX-LIST and not a key-existence check ──
A loaded index registers in the index registry but reads ABSENT to a plain key-existence
probe. The earlier draft used the existence check — every healthy activation would have
reported ACTIVATION-FAILED. The adversarial re-run caught the discriminator before ship;
the gate now asks the index registry directly.

The disposable acceptance harness reaching REAL ONBOARDED

evidence/b8-harness-009.log · 2026-02-03T02:24Z · excerpt, reconstructed

The witness run: stocktrace_ob + partline_ob both exit 0 through the full ED-46 chain in an isolated disposable runtime; production runtime untouched. This harness caught 4 more runtime bugs the diff-review missed before it passed.

── reconstructed excerpt · transposed from the real record ──

# Disposable acceptance harness — REAL ONBOARDED (ns=stage-a, production untouched)

RUN: canonical provision (stocktrace seed + partline spec) → resolved-triple ingest
     → catalog → activate (force-recreate) → 3-layer loaded gate → ONBOARDED exit 0

[stage-a] stocktrace_ob : ONBOARDED exit 0 — L1 ✓  L2 ✓  L3 ✓  (Activation VERIFIED)
[stage-a] partline_ob   : ONBOARDED exit 0 — read-only, spec shape
[stage-a] F-2 idempotent re-activate: BOTH profiles preserved, source_count=2
[stage-a] W-union : registry/list serves BOTH families, zero collision (stocktrace_ob.*=3, partline_ob.*=2)
[stage-a] W-idx   : per-source indexes BOTH present
[stage-a] D2a     : generated partline_ob profile has NO write_entity (read-only honest)
[stage-a] D2b     : no write-class command authored for read-only partline_ob
[stage-a] D2c     : write-capable stocktrace_ob declares write_entity
[stage-a] F-3     : WRITE command planted under LOADED read-only partline_ob
                    → boot refused: "WRITE-class command registered for a READ-ONLY source — ABORT BOOT" [EXIT 6]
[stage-a] negative: sidefeed_ob without activation → AUTHORED-INCOMPLETE exit 2
[stage-a] negative: catalog-builder missing → AUTHORED-INCOMPLETE exit 2 naming the ingest step
[stage-a] PROD-UNCHANGED: live runtime id + start-time identical before/after, every run

── provenance ──
This harness was the FIRST runtime exercise of the repaired activation path (the two prior
fixes were diff-verified only). Before it passed, it surfaced FOUR issues invisible to diff
review — a malformed ingest invocation, a seeds mount present in the dev stack but missing
from the release stack, health-capture output pollution that silently skipped the 3-layer
gate, and a command-name collision. Each was fixed and re-run. Only then did REAL ONBOARDED fire.

AC-78 ONBOARDED witness record

evidence/b8-witness-005.md · 2026-02-03T02:37Z · excerpt, reconstructed

The witness close: what was proven, on which binary, with the negative controls.

── reconstructed excerpt · transposed from the real record ──

# AC-78 — disposable acceptance harness witness: REAL ONBOARDED on the repaired provision path

Subject: the AC-78(a) ONBOARDED product-path proof on the ED-46-fixed provision script,
as ONE isolated disposable runtime, live production runtime untouched (asserted unchanged).

## Headline — REAL ONBOARDED achieved
The correlated product path runs end-to-end in one attributable transcript:
canonical provision (both source shapes) → resolved-triple ingest → catalog →
activate (force-recreate) → 3-layer loaded gate → ONBOARDED exit 0 → both profiles LOADED + SERVING.

## Per-arm verdicts (labeled by evidence strength — every row cites its transcript line)
ONBOARDED stocktrace_ob exit 0, full chain ......... PASS  directly-witnessed
ONBOARDED partline_ob exit 0, read-only spec shape . PASS  directly-witnessed
idempotent re-activate preserves both .............. PASS  directly-witnessed
registry union, zero collision ..................... PASS  directly-witnessed
read-only honesty (no write_entity, no write cmd) .. PASS  directly-witnessed
planted-write refusal at boot [EXIT 6] ............. PASS  clean runtime fire
AUTHORED-INCOMPLETE negatives (2 forms) ............ PASS  directly-witnessed
production isolation ............................... PASS  every run
ACTIVATION-FAILED induced exit-3 ................... PARTIAL — rollback witnessed;
  clean induced exit-3 on the repaired script registered as carry-forward, with the
  reason documented (the broken-binary induction trips an earlier failure first).

## Residuals (named, not hidden)
- release-stack seeds mount gap (registered)
- an unhealthy-reload edge where the honest-terminal branch is dead code under strict
  shell error mode (repro confirmed; healthy path unaffected)

The frozen evidence manifest (AC-65..78)

evidence/b8-manifest-001.md · 2026-02-04T01:26Z · excerpt, reconstructed

Every AC row pinned to raw evidence files. Round-3 caught this manifest violating its own direct-evidence rule on AC-78(a).

── reconstructed excerpt · transposed from the real record ──

# FINAL FROZEN EVIDENCE MANIFEST — AC-65..78 (sub-bar matrix)

Single authoritative gate handoff. Per the gatekeeper's round-2 framing: a per-SUB-BAR matrix
(not one compressed row per criterion) — each sub-bar points DIRECTLY at its raw transcript;
this document is only the index; source-code arguments are corroboration only. Superseded
artifacts are marked [HIST]. Binary attested: build-4471 (the shipping build).

AC-65  stack healthy + ready-line      b8-witness ready-line log — cache store + secrets
                                       service + runtime all healthy; ready event on the
                                       attested build. [HIST: the earlier log, pre-attestation]   PASS
AC-67  catalog produced / schema-valid catalog witness — 7 calls ingested, validator pass
                                       [HIST: index row merely asserted it]                        PASS
AC-69  READ from cache, zero source    zero-source-read witness W-1/W-2/W-3 — cached entity
       calls, budget unchanged         served; source-journal delta=0 across 20 reads;
                                       budget unchanged. [HIST: structural argument = corrob]      PASS
AC-70  commit → Committed              commit-bracket record (Committed{state, provenance})        PASS
AC-70  independent cache observation   FRESH post-commit cachectl read — correlation id equals
                                       the verdict's [HIST: the earlier cache log was STALE —
                                       flagged by the trinity audit, enforced by the gate]         PASS
AC-71  reject → no write fired         reject record + write-journal delta=0 + cache byte-
                                       identical + a Committed control proving delta detection     PASS
AC-73  outbound works + observable     raw witness + change-window independence attestation —
                                       labeled ATTESTATION-CURRENT, not a fresh runtime re-run     PASS
AC-78  multi-source in ONE runtime     union registry listing; per-source namespaces; cross-
                                       source independent governance; ONBOARDED witness            PASS

STATUS: round-5 / REAL ONBOARDED — witness-complete; this block supersedes every other
status line in the file.

The architect's own adversarial audit

evidence/b8-audit-001.md · 2026-02-02T18:05Z · excerpt, reconstructed

Internal adversarial pass that preceded the external gate — including the stale-cache store-witness flag the external gatekeeper later enforced on AC-70.

── reconstructed excerpt · transposed from the real record ──

# Architect Adversarial Re-Audit (trinity leg b) — AC-65..78

Verdict: PASS-WITH-FINDINGS (1 issue → diagnosis, 3 minor notes)
Method: read EACH of the 14 canonical evidence files against its VERBATIM close-bar,
adversarially — NOT trusting the evidence index's "PASS" (several index PASSes key off the
outcome label rather than the witnessed behavior — a known trap class).

Selected rows:

AC-67  "schema-valid" is ASSERTED in the verdict line — no validator run witnessed in the
       cited file. Flagged for a confirm.                                    PASS (note)
AC-69  the zero-source-call claim was closed structurally (the read engine holds no source
       adapter handle — type-level unreachable). The external consensus later ruled
       witness-required; closed via a delivered runtime witness; the structural argument
       demoted to complementary design-proof.                                RECONCILED
AC-70  the cited cache-state log is STALE (captured hours before the commit it is meant to
       witness). The committed record carries the written state, but the independent
       cache observation must be a FRESH post-commit read.                   ISSUE → fix
AC-78  union and cross-source governance witnessed; per-source index and namespace
       isolation ASSERTED but not externally observed — no listing showing the two
       distinct namespaces.                                                  PASS (note)

The stale-witness flag on AC-70 is the one the external gate independently enforced in
round 2. Internal adversarial pressure and the external gate converged on the same hole.

Round-2 regate supplements

evidence/b8-note-015.md · 2026-02-02T19:31Z · excerpt, reconstructed

The supplement that admitted full bootstrap was avoided — the honesty that let round 4 pull the thread.

── reconstructed excerpt · transposed from the real record ──

# Re-gate round-2 — 3 precise witnesses (all PASS)

Closes the 3 witness items from the round-1 dispositions. All on the deployed build-4471.

## Hole 1 — delta-path upsert (not full-reconcile) → PASS
Witness profile with a long full-reconcile interval on a controlled mock source:
startup reconcile upserted entity W-1; W-2 ABSENT (not in source at load). Mid-run ADD of
W-2 to the mock source → the next DELTA cycle upserted it: EXISTS 0→1, watermark advanced,
with delta_start=1 and full_reconcile_start=0 since the add — unambiguously the delta path.

## Hole 2 — onboarding flow for BOTH source shapes → PASS
Ran the catalog-builder Pass-A ingest for each shape (witness output names; production
catalog/profiles/commands untouched — FULL provision would re-author commands and restart
the runtime, risking the custom handler under test):
- stocktrace (seed): ingest exit 0 → 7 calls, validator OK
- partline (spec v3): ingest exit 0 → 98 calls, validator OK

NOTE: this supplement says plainly that full provision was AVOIDED and why. That honesty is
what round 4 later pulled on — the composed evidence was disclosed, not disguised.

## Hole 3 — commit + independent cache observation → PASS
A governed update → outcome Committed (read-back state inline). Then a FRESH cachectl read:
the cache record's correlation id equals the Committed verdict's — the cache was written BY
this commit, independently observed, changed from its pre-commit value.

Gate PROCEED-round dispositions

evidence/b8-verdict-002.md · 2026-02-02T18:41Z · excerpt, reconstructed

How each gate hole was dispositioned (accept / fix / carry-forward) on the way to the round-5 proceed.

── reconstructed excerpt · transposed from the real record ──

# Gate round-1 — proceed-with-changes dispositions (3 holes, all ACCEPTED)

## Hole 1 — AC-75 scope honesty → witness lane
The criterion requires THREE sub-bars: delta upsert + watermark advance + phantom evict.
The post-fix witness covers only phantom-evict; the race log's watermark was frozen by
contention. Disposition: run the existing delta harness on the deployed build → prove the
delta/watermark halves post-change. Cheap (existing harness).

## Hole 2 — no frozen final evidence manifest → team-lead
The regenerated index still carries stale rows SUPERSEDED by later artifacts. A reviewer
should not have to reconcile a stale index + appended audit history + packet overrides.
Disposition: author ONE frozen per-sub-bar manifest pointing each cell at the CURRENT raw
witness, superseded artifacts marked historical, source-code arguments demoted to
corroboration. The single handoff artifact for the re-gate.

## Hole 3 — "no write fired" is structural, not witnessed → witness lane
The rejection record proves the reject; "no write fired" was closed by source-path
reasoning — the same class the adversarial consensus ruled witness-required elsewhere.
Disposition: capture an external before/after cache check + a write-journal delta around
the rejected call.

## UPDATE — supplement results
- Hole 1 = PASS (delta-upsert + watermark-advance witnessed post-change)
- Hole 3 = INVALID — REDO. The first supplement tested the WRONG case: a mutate with no
  policy check on that field → it Committed and fired a write. The redo bar: on ONE source,
  witness BOTH (a) a policy-VIOLATING mutate Rejected with write-journal delta=0 + cache
  unchanged, and (b) a Committed control on the SAME command firing delta=1 — proving the
  journal detects writes, so delta=0-on-reject is dispositive, not a broken-journal artifact.