VSS Gaming-GPU — Execution Ledger¶

Spec (source of truth): docs/superpowers/specs/2026-09-23-vss-gaming-gpu-profile-design.md (rev 5; the rev-4 cite here was stale until this row fixed it — see F10) · Brief: docs/vss-integration/13-implementation-brief.md · Branch: feat/vss-gaming-gpu-profile · Phase plans: G0 (CLOSED 2026-09-24) → P0 (CLOSED 2026-09-25 — M0) → Phase 1 (current; one phase at a time)

One row per step (G0.1…4.3) and per spike (S-1…S-5). Statuses: TODO · DOING · DONE · BLOCKED (reason) · NA. A milestone row closes only with its S# numbers and a commit. Evidence carries the [V]/[C]/[E]/[?]/[O]/[A] markers per docs/vss-integration/AGENTS.md. A step closes on an executed command + result + commit, never on written code.

Environment of record (row 1)¶

Phase G0 — GB300 development environment¶

Risk spikes (brief §"Spike before building")¶

G0 — phase close (2026-09-24, owner directive "close out G0")¶

Counting erratum: the "61 risk_score sites" (step 0.25)¶

Spec §8 step 0.25 says 61 sites at 4eab98e5, found with grep -rnE 'risk_score\s*(>=|<=|>|<)' [V spec:386-387]. Not reproducible by any scope tried (re-run 2026-09-24; the grep set is byte-identical at 4eab98e5, at d3841e19, and at G0-close HEAD, so the counts below are stable across those SHAs — an earlier "at HEAD d3841e19" label here was itself stale, d3841e19 predated this ledger):

Recipe A + arithmetic = 58 confirmed at G0 close (2026-09-24). The 4 arithmetic-only sites are real live-path code, not docstrings: analytics.py:418 (histogram risk_score / bucket_size), experiment_result.py:117 (abs(v1 - v2)), calibration_service.py:407 (risk_score / 50.0), pipeline_quality_audit_service.py:314 (abs(audit.consistency_risk_score - event.risk_score)) — all four TypeError on a NULL score, so all four belong to the 0.25 audit surface. (The + - * // prose earlier in this row was an invalid ERE, [+-] alone parses as a range; the valid class is [*/+-].)

Working set for step 0.25: the 54-site recipe (live comparisons, tests excluded) + the 4 arithmetic sites = 58. The true code surface is smaller still: many of the 54 are docstrings/OpenAPI descriptions, not live code — a per-site triage belongs in the 0.25 plan, which will classify each as live-path / dead / comment. The "61" figure is superseded; the dated errata entry is already written — N1–N7 exist in docs/vss-integration/11-errata-2026-09-23.md (this row's earlier "not yet written" was stale; corrected at G0 close). Spec text stays untouched per the brief.

P0.25 — null-safety: triage and shipped set (2026-09-25)¶

Triage of the 58-site surface (54 comparison + 4 arithmetic, recipe [*/+-]), adversarially re-checked (6-cluster workflow wf_a178969e-6f0 + direct code reads adjudicating its exclusions): 5 of 8 named consumers were already NULL-safe — alertengine:451 (is None or < since the file's first commit), analytics:418 SQL (WHERE risk_score is not null), experiment_result:117 (columns nullable=False), calibration:407 (caller guard adjust_from_feedback:250, already pinned by its own test), audit:314 (is not None and guard, already pinned) — plus validators:191/198 (callers pass schema-validated ints), event_repository:156 (SQL WHERE excludes NULL), sampling:355 (isinstance guard), trend_service:116 (guarded is not None upstream), models/event.py:41-45 (_compute_risk_level guards None first — verified via workflow caller-trace: FastAPI returns {"risk_score": null, "risk_level": null} cleanly), the rest docstrings/OpenAPI prose/SQL expressions. Correction to the counting erratum above: "all four arithmetic sites TypeError on NULL" was wrong — direct reads + 4 green pin-tests (test_null_score_p025.py::TestArithmeticSitesAreAlreadyNullSafe_PINS) show each is NULL-safe by a different mechanism; the sites still belonged to the audit surface (they were checked; two already had pin tests) — the _reason was wrong, the inclusion was right.

Fixed (red-first, test_null_score_p025.py: 8 red → 16 green): WebSocketEventData.risk_score/risk_level → Optional (spec §4; both WS contract tests updated to assert the new anyOf-with-bounded-scored-branch shape); requires_ack null-safe (risk_score is not None and >= 80; critical-level arm keeps ack; a None event no longer TypeErrors the subscriber loop); notification_filter.should_notify §6-step-3 detector-only rule before any level/threshold comparison (new detection_class/detection_confidence params; SECURITY_RELEVANT_CLASSES = {person, vehicle} exactly as spec names — widening is an owner call; NULL+strong→notify even past a 90 camera threshold, NULL+weak/non-security/no-evidence→suppress; global-disable still first). Frontend: SecurityEventData.risk_score/risk_level → | null; ActivityFeed draws an Unverified chip instead of a badge (design is 1.6's; this is no-crash/no-lie), DashboardPage gauge shows latest known score (never zero-for-a-lie), riskHistory drops unscored points, LiveActivitySection counts/surfaces nothing for unverified. getRiskLevel untouched — its throw-on-non-number is the no-lie guard.

Gates [V]: unit 27,988 passed (1 known systemctl env fail), contracts 612 (612 with updated pins), integration failure-set byte-identical to clean-HEAD baseline (Redis/shutdown flakes pre-existing; targeted HEAD runs prove the flake, diff of sets empty), vitest 1061/1061 + typecheck clean, gen-ai-contract.py --check current. Legacy diff = the approved set + nothing else: 3 backend files + 2 contract tests + 4 frontend files + 1 new test file (+110/−29 code, tests counted separately).

P0 execution notes¶

• P0.25 premise check — PASSED 2026-09-25 [V]. backend/models/event.py:58-60: risk_score and risk_level are both Mapped[int | None] / Mapped[str | None], nullable=True — the plan's STOP-AND-ASK trip (column NOT NULL ⇒ 0.3's premise breaks) does not fire; NULL scores are storable today. The gap is purely the WebSocket schema (websocket.py:252-253: risk_score: int = Field(...), risk_level: RiskLevel required) — exactly Task 2's edit target.

• P0.1 control freeze — CODE-DONE / execution-ruled-N/A 2026-09-25 [V] (F9). backend/evaluation/control_freeze.py ships tested: freeze = copy event images INTO the store dir (survives any later retention purge) + honest AssessInput snapshot (zones/household are NOT on event rows → empty, never invented) + control = the RECORDED score (Event.risk_score, falling back to parsing LLMInteraction.raw_response; no control at all → loud skip) + owner label via spec §5's table verbatim (false_positive→benign; missed_threat/accurate-on-high→incident with expected_severity, bare-accurate falling back to the event's own score band); provenance rides the item_id (pre-switch::{event_id}, no FK — the EvalItem contract has no linkage field and none was invented). Unlabeled events freeze with the EMPTY label (contract stays str as owner-reviewed; the frozen analogue of a NULL verdict; S2/S3 skip empties — a §5 item with no label still gets its control run, which is why unlabeled must not skip). Manifest = JSONL one row per item incl. loud-skip rows with reasons. D10: store + media-root residence prefight (repo/capture root = whole-run ControlFreezeError, not a skip), per-source containment guard (no copy from inside the media tree), EvalStore.put_item still decides item media at write time. Tier note: aiosqlite is NOT in this repo's dependency set — the plan's "sqlite or the test PG" fixture branch taken is the TEST PG: core unit-pinned on fabricated loaded rows (21 green), ORM seam live-PG-pinned (3 green, same-session compose, E11 honored). Commit: c115fed5 [V] — P0.1+P0.4 shipped as ONE commit (its stat: 23 files, +2553/−22). Focused units: test_control_freeze.py 21 passed + test_event_verification.py 12 passed; integration test_p01_control_freeze.py 3 green on the live test PG.

• P0.4 event_verifications + verification — SHIPPED 2026-09-25 [V]. Table event_verifications (spec §4 columns; verdict CHECK; JSONB criteria/key_frame_detection_ids; Event.verifications selectin like detections so the API reads rows with the event, no N+1). Migration = the model (create_all-only doctrine, #4465: creates NEW tables on an existing DB, never alters) — pinned live: drop the table under a populated DB, create_all restores it, rows untouched. Retention call (plan Task 4 box 2): CASCADE, not the FK-less provenance row — cleanup's Core event hard-delete must not orphan or FK-500, and nothing needs to survive retention here because eval items are self-contained (D7: media copied in, snapshot self-contained; a surviving row would serve no metric). FK ondelete="CASCADE" + ORM cascade/passive_deletes mirror; sweep pinned live (ORM and Core delete paths). Payload: REST EventResponse + WebSocketEventData gain verification via ONE shared schema (snake_case, §3 drift doctrine), exclude_if=None → KEY ABSENT for legacy (byte-identity), present on every row-carrying event incl. verification_failed so consumers branch on the verdict; selectable sparse field; notification filter AST-pinned to consume ONLY risk_score (structural pins: signature, call-args, level-bound-from-mapper-only, module never names verification) — a verification can never silently feed notifications. Gates [V]: unit 28,058 passed (1 known systemctl env fail), contracts 612, live integration 9 new green + 96 events/cleanup regression green, openapi/api.ts regenerated + checks green, ws-types generator taught nested payloads + --check OK (was red at HEAD — pre-existing P0.25 gap, CLOSED here: generate-ws-types.py now emits VerificationCriterion/EventVerificationPayload and maps datetime→string; the regeneration also carries P0.25's already-shipped nullable risk_score/risk_level into generated/websocket.ts, which is what the stale check had been hiding), frontend typecheck clean, gen-ai-contract.py --check current (untouched — VSS-internal, as the plan expected). Existing pins updated where this slice's contract changed the pinned surface: schema snapshots (pure ADD — diff shows +312/−0 on the legacy snapshot bytes) and test_valid_event_list_fields_complete (allowlist +verification). Commit: c115fed5 [V] (shared with P0.1 above; focused units 21/12/14/7 passed; live integration 9 new green same-session with compose healthy; snapshots --snapshot-update 19 passed + 2 updated, .ambr diff +312/−0 — legacy bytes unchanged; unit 28,058 passed/1 env-fail; contracts 612; openapi/api.ts/ws-types checks green; frontend typecheck clean; gen-ai-contract.py --check current).

• P0.4 box 4 (0.3 producer wiring) — deliberately NOT this slice [V]. nemotron_analyzer.py is the concurrent 0.3 agent's in-flight file (single-writer rule); the table + payload render verification_failed end-to-end TODAY (live REST test writes exactly that verdict through the API), so the 0.3 slice only has to write the row. WS producer passthrough inherits from the schema (broadcaster dump drops the absent key; validated objects pass through — unit-pinned).

• P0.5 labels + imports — CODE-DONE 2026-09-25 [V] (F5/F9 sizing: born-labeled, no human-labeling stage; owner labeling EXECUTION box stays open for a returning home stack). backend/evaluation/label_import.py ships TDD-first (red: ModuleNotFoundError: No module named 'backend.evaluation.label_import' → green). Three duties: (1) import_loaded_event/import_event = §5 "post-switch" row — only LABELED events import, through the SAME map_feedback the freeze pins (one source for §5's table); provenance rides post-switch::{event_id} (no FK); media COPIED into the store (survives retention purge, freeze's _copy_into_store + media-root D10 preflight shared); control = placeholder offline-30b-replay-pending with control_score None — the placeholder-pipeline verdict is forbidden as control by §5 row 2, and expected_score = the severity band FLOOR (S3 asks "at or above the minimum", never the recorded score). Unlabeled/accurate-on-low/severity_wrong → loud skip, store row absent = the S2/S3 exclusion made real. (2) import_generated_items = the media-bearing synthetic import for post-Task-0 clips: born-labeled (category from generator placement, load_synthetic_items' committed vocabulary; expected score = declared band midpoint, severity = that band's level for incidents only), manifest frames contained (audit #1 rule: an escaping manifest REFUSES the set, never scans around it), no-media sets skip loudly (they stay load_synthetic_items DRAFTs — inventing a path would be D10 fabrication); ids generated:… never collide with draft synthetic:… ids. The replay harness itself stays Phase 2.1's (not built here, per plan). (3) m0_size_report = the 100-benign/20-incident bar as code (M0_MIN_BENIGN/M0_MIN_INCIDENTS, reasons list, m0_complete only when both clear); unlabeled excluded from BOTH sides, unknown labels surfaced not hidden. Manifest JSONL incl. loud skips (freeze doctrine). Tier split: core unit-pinned on fabricated rows (33 green, test_label_import.py), ORM seam live-PG (5 green, test_p05_label_import.py, same-session compose 5433/6380 healthy, E11 honored). Bar observation [V, read-only: m0_size_report over the owner-ruled frozen store out/eval-store/eval.sqlite: benign 139 ≥ 100, incidents 282 ≥ 20, unlabeled 0, m0_complete: True — the count that clears the code bar is the BORN-LABELED synthetic corpus already frozen (F9's restatement of M0 piece 2); no real-camera labels involved. Gates [V]: unit 28,091 passed (1 known systemctl env fail), contracts 612, integration tier: 5 new green + tier run failure-set 12 = byte-identical baseline (Redis/shutdown/shadow/nemotron flakes; proven pre-existing by re-running the identical 12 with this slice's three files moved aside — same 12 fail; first-run's 263 error burst was a load flake, second run zero errors); gen-ai-contract.py --check current (untouched). Diff = 2 new backend files + 2 new test files + this row; zero edits to any existing file. Commit: 5300b455 [V] (unit test_label_import.py 33 passed; integration test_p05_label_import.py 5 green same-session; commit stat = exactly those 4 files + this ledger row, +1298).

P0 execution rows — 2026-09-25 slice run¶

Gate-tooling erratum, 2026-09-25 [V]: the goal's commit-message recipe (uv tool run pre-commit run conventional-pre-commit --hook-stage commit-msg --commit-msg-filename <file>) FALSE-REJECTS any dotted scope — it mis-parses feat(p0.25):/feat(p0.3): and even rejects the already-accepted b79bbb1f message verbatim (proved by running the wrapper against it). The tool's own direct invocation validates both. Use uv tool run conventional-pre-commit <file> (optionally with the repo's allowed types feat fix docs chore refactor test) for dotted-scope messages; the wrapper stays fine for undotted scopes. Amendment 2026-09-27 [V] — the types are SPACE-separated, and passing them comma-joined silently disables the check's allow-list. uv tool run conventional-pre-commit fix,feat,docs /tmp/msg.txt makes the tool treat the whole string as ONE type, so nothing matches and only its built-in defaults (feat, fix, perf, refactor, ci, build, test) still pass: a fix(...) message validates and the check looks healthy, then the first docs(...) message rejects and reads like a message defect. Caught exactly that way — a real, valid docs(vss) message was rejected, diagnosed by bisecting to a header-only file, and confirmed against the repo's own hook args (.pre-commit-config.yaml, which lists the types one per line). The safe invocation is the no-types form, which reads the repo config: uv tool run conventional-pre-commit /tmp/msg.txt. The same commit produced a second, worse process fault worth the row: the rejected check was chained check && commit && push in one shell call, so a non-zero gate did not stop the commit. The message itself was fine (both correct invocations return 0, so nothing was pushed in violation of the hook config), but the ordering was — a gate whose exit code is consumed by the next command in the pipeline is not a gate. Check, read its exit code, THEN commit, in separate calls.

P0 — phase close (2026-09-25: M0 met)¶

M0 (rev 5, spec §8 Phase 0) = Phase 0's code merged with every CI tier green, and the eval store at the size bar. Both hold:

• Merge [V]. PR #6678 squash-merged into main as a0105b63 at 2026-09-25T13:02:23Z, head cdb24bc7, automerge SQUASH enabled by the owner (12:42:37Z) — the owner's merge call, made by enabling automerge. Post-merge check-run sweep on cdb24bc7: all checks success or skipped, zero failures — the one non-success row is Trivy: neutral, its advisory non-fail conclusion. Tier set: Collection Sanity, unit 1–4/4, integration umbrella + API shards 1–4/4 + Services + WebSocket + Models, Frontend Vitest 1–8 — all green. The PR merged on the head that carries the shipped-wire doctrine (53a64cfd) and the ratchet fix (cdb24bc7), so both CI lessons are banked in main.
• Eval store [V]. m0_size_report (bars M0_MIN_BENIGN=100/M0_MIN_INCIDENTS=20 at label_import.py:84-85): benign 139 / incidents 282, m0_complete: True — read-only observation over $AGENT_GPU_DIR/out/eval-store/eval.sqlite re-verified 2026-09-25; aggregate numbers only, per D10.
• P0 code provenance: shipped 0.25 null-safety (row above), 0.3 constrained verdict + shared enforcement seam (c8bb0428, rev-5 amendment: sandbox half only), 0.4 event_verifications + verification field (c115fed5), 0.5 labels + size bar in code; 0.1/0.2 execution removed by F10. Rev-5 DoD met item for item; the legacy diff stayed the approved 0.25/0.3 set.
• Follow-up pushed post-merge [V]. The Phase 1 plan (docs/superpowers/plans/2026-09-25-vss-phase1-vlm-path.md, drafted 2026-09-25, local 5e22e5a6) rode above the automerge head deliberately — pushing it pre-merge would have re-queued the unit shards. After the squash, git reset to a0105b63 + cherry-pick + --force-with-lease put it on main's tip as b97ab83b (squash-merge history makes a plain rebase replay-and-conflict; this is the documented sync-after-squash shape). Backup ref backup/pre-plan-reset tags the pre-reset tip.
• Milestone review: each milestone closed with the built-in code review at its own slice time (G0 close, P0 slices, the PR's own review rounds — the ratchet/wire fixes came out of it); the merged diff got no separate re-review, recorded as-is rather than claimed.

Next: Phase 1, tasks 1.1 → 1.7 per the new plan. Decisions owed unchanged: S2_MAX/S3_MIN before 2.2, VLM pick at M2, go-live 3.1, Brev spend at 2.3, 1.7 bring-up timing.

Dated correction, 2026-09-28. The line above is kept as written because it records what was next at P0 close, but it is no longer the state, and a stale "current" line actively misdirects a fresh session. As of today: Phase 1's repo-side half is committed through 1.7 and M1's review is CLOSED [V]; Phase 2's repo-side half is closed too (eval store gen-2, the replay harness, the tool probe, candidates A/B/C, the bake-off report, the larger-model survey). The M2 pick is made — Qwen3-VL-8B-Instruct Q4_K_M, owner ruling 2026-09-28, spec rev 7, item 35 — so "VLM pick at M2" is no longer owed; what is owed there is M2 closure, which only the owner's runs produce. Current blockers are hardware-shaped, not code-shaped: the A5500 bring-up (1.7's owner-run half, which carries S1 and S4 — the two bars F13 reserves to 24 GB-class hardware), the Brev matrix decision, and item 19's real corpus (the only thing that can answer S2/S3). Decisions still owed by the owner: the S2_MAX/S3_MIN [?] rows in the spec's S-table, Brev spend, go-live 3.1, and every PR/merge.

Phase 1 — VLM path (plan: docs/superpowers/plans/2026-09-25-vss-phase1-vlm-path.md)¶

| step | status | date | command | result | commit | | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------- | | 1.1 the contract | Commit 030b378a (the vlm_assess op, generated schemas, VLM provider slots, fake faults). [V] | 2026-09-25 | uv run pytest backend/tests/contracts/ -n0 --timeout=30 → 646 passed; uv run pytest backend/tests/unit/ -n auto → 28,402 passed, 1 failed (pre-existing: test_deploy_phases::test_skips_when_skip_build shells out to systemctl, absent in this sandbox — re-proved on clean HEAD via stash; unit item 14 already banks this known env-fail); uv run python scripts/gen-ai-contract.py --check → "AI contract is current"; scripts/check-ai-provider-parity.py --expect .github/ai-parity-baseline.json → exit 0, vlm_assess surfaces as DECLARED informational; generator+parity script suites 47 passed | op 38 vlm_assess declared in scripts/gen-ai-contract.py VLM_OPS (registered path /vlm/chat/completions — the real engine wire /v1/chat/completions is owned by llm_chat_completion's op.path and the fake double-mounts; real spelling lives in the evidence column for 1.3's vlm_client). Schemas+goldens GENERATED from backend/services/vlm_verdict.py (VlmVerdict/VlmAssessRequest, pydantic model_json_schema() — schemalive-model equality pinned in scripts/test_gen_ai_contract.py::TestVlmContract); request side mirrors event_verification.AssessInput (field-set equality pinned) and reuses VerificationCriterion. ProviderId.OPENAI_VLM/RTVI_VLM minted → per_model_server union column, required={"vlm_assess"}, deployed=False (compose=1.2, client=1.3) — subset-in-union, the llamacpp pattern (closes open-issue 8). Five provider-keyed test modules updated for the new ids: absence/spine guards generalized through a SUBSET_REQUIRED table (a fourth subset provider now needs a row, not a branch), EXPECTED_DEPLOYED/EXPECTED_SIZES rows, vlm_assess added to the per-model not-wired census 7→8 (client_methods[] until 1.3), numeric/vocabulary loops extended to cover-not-skip the new ids, semantics sibling sentinel mirror synced. FakeProvider: deterministic verdict keyed on sha256(op_id \| image_paths \| profile)(same-images byte-replay / different-images variety pinned) + the §7 ladder fault knobsx-fake-fault: 5xx \| schema-invalid \| timeout[:SECS](TDD red-first, 3 red → 13 green; hermeticity pinned — no-header path byte-identical, unknown value falls back healthy, per-request so profile determinism is untouched). AGENTS.md counts 37/43/43 → 38/45/45 (validator is human-facing prose, no automated checker found). Parity baseline: no edit needed — the ratchet gates only CLAIM/finding ids (missing/extra vs baseline at :1398-1409);DECLAREDlines are informational adjudication andvlm_assess reads DECLARED natively (no caller builds its URL, so CLAIM-GW404 cannot arise; the plan bullet's premise predates the checker's actual semantics — recorded per the doc-vs-repo rule, adjudication here, not a spec edit). | this commit | | 1.2 the ai-vlm service + vlm profile | Commit 8d39f1b6 (the compose service, vlm profile, 8098 env-first, live GB300 serve; the deploy-path client wire the M1 review later found missing was 2ea790bc). [V] | 2026-09-25 | flag precheck: agent-gpu run --image ai-vlm:sm103 --vram 4 --wait -- llama-server --help (b7972) → --sleep-idle-seconds/--alias/--jinja/--parallel/--mmproj all present before wiring them; build: agent-gpu build --context workspace:ai/vlm --tag ai-vlm:sm103-v12 --build-arg CUDA_ARCHITECTURES=103 → succeeded (runtime-stage steps only; G0's sm103 image kept intact); serve: agent-gpu run --name vlm-serve-12 --image ai-vlm:sm103-v12 --vram 14 --port 8098 --mount models:/models --env MODEL_PATH=/models/vlm/Qwen3VL-4B-Instruct-Q4_K_M.gguf --env MMPROJ_PATH=… --env MODEL_ALIAS=Qwen3VL-4B --env SLEEP_IDLE_SECONDS=300 --env GPU_LAYERS=auto --env CTX_SIZE=32768 --env PARALLEL=2 --env PORT=8098 → admitted at 14336 MiB, /health {"status":"ok"} ~10 s; agent-gpu logs: "model loaded … listening on 0.0.0.0:8098"; probe: uv run python scripts/vlm_probes/s2_multimodal_schema.py --base-url http://host.docker.internal:18100 --image gpu/out/media/stock/vandalism/003.jpg → verdict ENFORCED (arm B echoed const 92c6ffde… schema-shaped; arm C not the empty object; build_info b7972-e06088da0); agent-gpu rm both containers → containers: [], free 49064 MiB [V] | .env.example FIRST (root rule): AI_VLM_PORT=8098 into the AI SERVICE PORTS block + VLM_MODEL_PATH/VLM_MMPROJ_PATH (prod.yml ${VAR:-default} style, not ghcr's literal). docker-compose.prod.yml: ai-vlm behind profiles: [vlm], ports: 127.0.0.1:${AI_VLM_PORT:-8098}:8098 with CONTAINER port fixed (PORT=8098, internal URL ai-vlm:8098 never depends on the host var); weights host-mounted :ro at /models; hardening byte-identical to ai-llm (test_security_hardening_consistency sweeps it — ai-vlm joined both curated AISERVICES lists); no depends_on, backend does not depend on it (profiled service in depends_on breaks default up — degradation is 1.3's §6 ladder, recorded per plan). ctx values chosen + ledgered: CTX_SIZE 32768 / PARALLEL 2 → 16384/slot ≥ ~12.2K worst case (4 images × ≤1280 + ~6K text + ~1K output), comment mirrors ghcr.yml:277-285's method; SLEEP_IDLE_SECONDS=300 = §2 residency mechanism (1.4 layers control on top). ai/vlm/Dockerfile: PORT/EXPOSE 8080→8098, guarded MODEL_ALIAS→--alias + SLEEP_IDLE_SECONDS→--sleep-idle-seconds CMD wiring (same unset-at-build doctrine as MMPROJ_PATH), one-Dockerfile/two-hosts note (103 aarch64 dev / 86 x86 A5500 via build-arg — no per-host fork; ghcr.yml stays OUT of Phase 1 per plan). Broker lesson learned: the build policy refuses non-ASCII bytes in the context (my § comment byte 0xc2 refused) — Dockerfile comments are ASCII-only from here; compose files keep house-style Unicode (19 pre-existing non-ASCII lines). Docs: AGENTS.md port table + 8098 row; env-reference.md NOT edited — the file carries zero LLM_MODEL_PATH-class coverage today, adding only VLM* would be inconsistent (ledgered instead). TDD: backend/tests/unit/core/test_ai_vlm_compose_service.py red-first (6F/14E with service absent → 20 green after), covers env-first ordering, profile, no-depends (both sides), port contract, budget arithmetic, flag wiring, security parity. Gates: unit 28,449 passed (1 known systemctl env-fail). Compose YAML parse + security/resource suites green (61 passed). Live docker compose up on the prod box is 1.7's owner-run A5500 bring-up; GB300 dev path = the agent-gpu serve above, per plan ("never by editing prod compose" — honored: the compose block was NOT used to serve; agent-gpu ran the image directly). | this commit | | 1.3 selector, client, analyzer, §6 ladder, wake-on-open | Commit 9b1b9899 (selector, client, analyzer, §6 ladder, wake-on-open; finding A's two legs 6106ea98/7141cad0, and the M1 review's three fixes on these surfaces d1e279fd/bdb55335/01080b51). DONE — code, every sandbox tier, AND the live GB300 wake/assess half [V] (broker was briefly unreadable — open-issue 15, closed 2026-09-26 with the executed live evidence appended there) | 2026-09-25 | TDD red-first per site. New: key_frame_selector.py (Hypothesis), vlm_client.py, vlm_analyzer.py (SIBLING — nemotronanalyzer untouched) + 4 suites. Edited: config.py (ai_vlm_url, house localhost-default + Docker-form description + validator join; .env.example AI_VLM_URL FIRST), metrics.py (hsi_ai_service_degraded gauge), sanitization.py (5 vlm*\*ladder labels into KNOWN_ERROR_TYPES — without them every VLM failure collapses to "other"),main.py(register ai-vlm on the DegradationManager singleton; machinery decision: the ladder hosts on spec-namedDegradationManager, health is BREAKER-PUSH, never probe-poll — §6's wake rule forbids a health probe waking a sleeping llama.cpp, so ai-vlm is deliberately NOT a ServiceHealthMonitor config), alert_engine.py+notification_filter.py(§6 rejected-gate),batch_aggregator.py(wake-on-open),providers.py/operations.py/gen-ai-contract.py(registry flip, not-wired census 8→7), integrationconftest.py(two real fixes, below). Gates:uv run pytest backend/tests/unit/ -n auto→ 28,517 passed, 1 failed (the knowntest_deploy_phases::test_skips_when_skip_buildsystemctl env-fail, same identity as the 1.1 baseline);uv run pytest backend/tests/contracts/ -n0 --timeout=30→ 646 passed;uv run python scripts/gen-ai-contract.py --check→ "AI contract is current"; integration (live Postgres :5433 + Redis :6380 — the sandbox's stand-in for the plan's "same-session compose-up"): full tier 4081 passed, 107 skipped, 2 xfailed, EXIT=0;test_vlm_analyzer.py5 passed (scored event on live schema; NULL-score event rides db→real-Redis pub/sub→WS frame re-validated againstWebSocketEventData; degradation-singleton push read through system.py's own reader); cd frontend && npm run typecheck clean (1.6 owns the frontend half) | Conftest, two real sandbox-tier fixes proven here: (a) worker_redis_url hardcoded :6379 while redis_container chose its local branch FROM TEST_REDIS_URL (:6380 here) — every real_redis consumer ERRORED (47 proved pre-fix via stash; 466 green re-run across the 9 consumer files; CI unaffected — it sets no TEST_REDIS_URL). (b) fixture-less RedisClient() consumers (e.g. TestRedisFailover) dial settings.redis_url; CI ships REDIS_URL as a service env, the sandbox declared only TEST_REDIS_URL → ConnectionError; conftest now mirrors it module-import (guarded: explicit REDIS_URL wins, CI never enters). Tier runnable-count jumped ~3300→4190 as those families started actually running. §6 ladder shapes (each pinned where it bites): rejected-gate is FIRST and unconditional in BOTH should_notify (param verification_verdict) and alert_engine._evaluate_rule — the rule gate reads verifications only when materialized ("verifications" in event.__dict__): a directly-constructed Event's collection is UNLOADED and touching it raises MissingGreenlet on the async engine (causal proof: the two alert integration tests fail with the naive getattr, pass with the probe; lazy="selectin" events stay gated). The analyzer's clamp is a score BOUND, never a skip — that's why the gate can't live in the clamp alone. Live-ness caveat, ledgered not silent: should_notify/evaluate_event have ZERO production callers today (the shipped live gate is Event-row + WS + requires_ack); landing the verdict gate in both is spec-§6 placement against a pre-existing live-wiring gap 1.3 does not introduce. Class-set note: SECURITY_RELEVANT_CLASSES spells person/vehicle; spec prose says "person, vehicle" — the repo's car/truck detections map elsewhere; unchanged, watched. Wake: create_task(wake_ai_vlm()) fires after the camera lock RELEASES, only on a NEW batch (unit pins: exactly-once; zero on reuse/threat/smoke-fire fast paths; enter→exit→create_task ordering proven); wake() = one real POST /v1/chat/completions max_tokens:1 and records record_model_cold_start("ai-vlm") ONLY on the 200 arm (a 503 woke nothing — counting it would skew the S4 budget); registry: both VLM ProviderIds now wired to VlmClient.assess; generated goldens unchanged (registry path stays the /vlm/ handle — the real wire /v1/chat/completions lives in op evidence). Fire/smoke bypass untouched (bypass paths pinned zero-wake). Selector coalesces same camera+class to ONE pick — integration assertion corrected to the design (junction keeps every detection). BLOCKED [A]: the live half (idle-sleep a served ai-vlm, batch-shaped wake, observe exactly one request) — agent-gpu CLI unreadable mid-session, open-issue 15; request side pinned in unit tests only. | this commit | | 1.3b the specialist stage | IN PROGRESS — shipped & gated [V]: the F12 face leg (SCRFD + w600k_r50, two hash-pinned CPU ONNX files, real-bytes proof) and the stage + analyzer wiring, every sandbox tier green. Enrollment/provenance half + the prompt-hygiene ruling CLOSED 2026-09-26 (752ad1e0 + 9cd44ae1, evidence appended below). Synthetic verdict-changing cases + the live per-batch budget CLOSED 2026-09-26 — row CLOSED [V] (evidence appended below) | 2026-09-26 | loader slice d3f60079; stage slice 3a8e2184 (6 files, +1250, pushed). Gates on the shipped tree: unit -n auto → 28,584 passed, 1 failed, 0 errors (sole failure test_deploy_phases::test_skips_when_skip_build — the known systemctl env-fail, same identity as the 1.1 baseline); contracts -n0 --timeout=30 → 646 passed; gen-ai-contract.py --check → "AI contract is current"; integration (live PG :5433 + Redis :6380, the E11 stand-in) → 4081 passed, 107 skipped, 2 xfailed, EXIT=0; frontend npm run typecheck clean. Real-bytes driver: loaded both pinned files (sha256 matches the models.yml rows) and ran the SHIPPED leg over two insightface test_res photos held in /tmp only (D10: nothing enters git) | Face leg (F12 option A closed): backend/services/face_recognizer_loader.py — load_face_detector:187/load_face_recognizer:163 (sha256 pin enforced; model_id = name@file@sha[:12]), detect_faces:302 (SCRFD decode verified line-for-line against the insightface reference: mean 127.5/std 128.0 blob, strides 8/16/32, 2 anchors interleaved at (row*W+col)*2+a, distance2bbox, 5×2 kps × stride, NMS iou 0.4), align_face_crop:418 (least-squares similarity onto ARCFACE_TEMPLATE:71, 112×112), extract_face_embedding:221 (L2-normalized 512-d, dim-guarded). ONLY those two ONNX files, onnxruntime CPU — no insightface.FaceAnalysis (its 5-model pack is where the old "~1.5 GB VRAM" came from). models.yml rows face-detector-scrfd/face-recognizer sha256-pinned; no license framing (owner ruling: licenses not a criterion). Stage inventory [V] (backend/services/vlm_specialists.py): face gallery/matcher face_recognition_service.py:401 match_face (session param unused; returns the 6-key dict); household vehicles via HouseholdMatcher.match_vehicle (plate wins, similarity 1.0); plate OCR fast_alpr_loader.py run_fast_alpr (the [alpr] extra — absent here, leg answers "unavailable", pinned); re-ID producer reid_service.py:430 (CLIP-768). Four outcomes as pure decision: classify_face_outcome:120 — the gate (passes_quality_gate:109, size AND score, inclusive edges) runs FIRST, a failing crop is not_identifiable, NEVER unknown (the S2 driver rule; pinned at both the classifier and the leg against a 24-px crop). Gate values from config, never constants: face_min_size_px=40 (config.py:1858), face_scrfd_threshold=0.6 (:1864), face_match_threshold=0.68 (:1872) — all three PROVISIONAL, calibration on the owner's gallery + night footage later; two later items ledgered WITHOUT building: AdaFace IR101/IR18 as the small/night-face bake-off challenger, CR-FIQA as a quality model. One embedding space (ruling 2, stage half): the leg reads the loaded recognizer's model_id; _gallery_model_ids:380 queries SELECT DISTINCT model_id FROM face_embeddings — any mismatch ⇒ "unavailable (re-enroll)", never a score; while the column doesn't exist the query answers ∅ (conservatively open, pinned) until the enrollment slice adds it. Re-ID honesty [V]: the household PersonEmbedding store is CLIP-768 (reid_service.generate_embedding; /clip router retired in vlm residency) and the resident Triton reid model is OSNet-512 — cross-space cosine is noise (cosine_similarity has NO dim guard; the np.dot raises), so the leg ships the no-score line naming both spaces until the gap closes. Follow-up swap for rev 7 ledgered (PersonViT ViT-S/16 MSMT17 R1 89.2, CLIP-ReID ViT-B/16 88.7); incumbent OSNet's "MSMT17 73.3%" is the multi-source MS+D+C→Market Rank-1 (single-source MSMT17→Market is 70.1). CLOSED 2026-09-27 — the gap is gone (ledger item 22, full swap): OSNet-AIN x1.0 512-d is now the one person-vector space end to end, CROSS_SPACE_REASON is deleted, and the leg answers with a real computation — match, no-match, or the owner's own "unavailable (re-enroll)" when the gallery carries only untrusted provenance. A PersonViT-class upgrade stays a later, separately-ruled swap. Threat call: NOT included — the card reports an identical 83.0% recall for EVERY class on an unnamed Roboflow set and calls itself research-only; published CCTV weapon AP50 is 57.4 and collapses to 3.7 across datasets (handguns 16–47 px). GATEWAY_ENABLE_THREAT stays false; SPECIALIST_KEYS:563 = {faces, plates, person_reid}; the rev-7 slot run_threat=True renders the explicit unavailable line (pinned both ways). Plate v2 OCR: could not check the installed fast-plate-ocr for v2 name acceptance here (extra absent) — v1 pin kept, swap skipped per the plan's clause. Analyzer wiring (vlm_analyzer.py:70, 460-472, 345): stage runs INSIDE session-1 (the face leg needs the DB gallery session) over the selector's picks — the same build_frame_refs feeds assess and the stage, so texts describe exactly the frames the VLM sees; texts ride AssessInput.specialist_outputs (the one carrier, 6737c750); replay passes stored texts and NEVER re-runs (pinned); a stage bug yields all-unavailable keys and the verdict still lands (belt pinned). S4 cost per face [V, CPU, idle]: detect median 100 ms @640 + embed median 68 ms/face (5 reps; contended first run 143/126 ms) — a worst realistic one-face-per-frame batch ≈ 0.4 s CPU, zero VRAM. Real-bytes proof: kun.jpg (325×402) → 1 face 126×168 score 0.83 → unknown, leg text "1 unknown face(s)"; embeddings unit-norm 1.0; woman.png → 423×606 @0.827 → unknown; SAME photo resized 80×100 (the owner's night case) → 31×41 crop @0.82 → not_identifiable, text "1 face(s) not identifiable (too small or low quality)", "unknown" absent — the ruling proven through the shipped leg on real pixels, not just fakes. Tier-hygiene fix shipped with the stage: the integration pub/sub test now matches frames by our uuid-unique batch_id — the channel is shared across xdist workers and Event ids restart per test (fresh schema), so first-frame-wins was a coin flip (deterministic flake under full-dir -n auto pre-fix; 5× clean after). PENDING boxes: enrollment server-side extraction (the two np.random.rand(512) placeholders at backend/api/routes/face_recognition.py:520,728, the client-vector add-embedding path's disposition, + FaceEmbedding.model_id column — schema create_all + conftest ADD COLUMN IF NOT EXISTS precedent); synthetic verdict-changing cases (benign known-face/household-plate vs suspicious unknown at night; + report whether S-3 uncertain hedging changes); live per-batch budget against a served ai-vlm (folds into M1's end-to-end smoke, which rev 6 defines as including specialist context). ENROLLMENT/PROVENANCE HALF CLOSED (752ad1e0, pushed) [V]: the two np.random.rand(512) placeholders are gone — both enrollment endpoints now run the SHIPPED pinned loader (SCRFD → align → w600k_r50) and store the LOADED recognizer's model_id. FaceEmbedding.model_id AND FaceDetectionEvent.model_id (the identify/queue copy paths move an EVENT's vector into the gallery, so provenance rides the event too) exist NOT NULL defaulting to the sentinel legacy-unknown-provenance — a row old code wrote without ever naming a model is flagged, never trusted, and the specialist reads a sentinel gallery as "unavailable (re-enroll)", never a score; identify_face_event copies the event's own id (both arms pinned: real id and sentinel). The client-supplied-vector endpoint is retired 410 Gone (a vector computed off-box cannot be trusted to share the space; enrollment goes through the image endpoints that run the loader; OpenAPI + generated TS regenerated with it — 1.6 consumes the regen). Absent weights fail loud at enrollment (a 5xx naming the cause), zero faces stays (None,None,None) → the 400 arm — the two arms kept distinct and pinned. Three-schema-twins lesson: with no Alembic this repo spells a column default in THREE places — the ORM model, docs/api/migrations/2026-09-26-face-embedding-provenance.sql, and the integration conftest drift-ALTER — and create_all never adds a column to an existing table, so they must agree EXACTLY; the integration tier proved it (21 red column face_embeddings.model_id does not exist until the third twin landed; then 43 passed face/vlm live, psql-verified the landed DEFAULT). SQLAlchemy quoting lesson (pinned by a DDL-render test, not the Python attribute): a plain-string server_default IS rendered quoted — f"'{X}'" produced '''X''' triple-quoted DDL, i.e. a gallery whose ORM-created and SQL-created rows carry DIFFERENT sentinel strings; test_emitted_ddl_default_matches_the_migration_sql compiles the CREATE TABLE and asserts the literal. 17 pins in test_face_enrollment_provenance.py. PROMPT-HYGIENE RULING SHIPPED (9cd44ae1, pushed) [V]: owner 2026-09-26 — "specialist_outputs is VLM prompt text, not a diagnostics channel." One funnel _unavailable_line(specialist, code, *, detail=None): the prompt gets ONE short model-facing line (_UNAVAILABLE_PHRASES: space_mismatch → "unavailable (re-enroll)", default "unavailable: specialist did not run"); the WHY goes to logger.warning with a bounded code (weights_absent/no_frames/detection_failed/embedding_failed/gallery_query_failed/frames_unreadable/gallery_unreadable/space_mismatch/leg_failed/space_incomparable/stage_error/not_included) AND counter hsi_specialist_unavailable_total{specialist,reason} — bounded vocabulary, no free-text label blowup. Applied to EVERY specialist (face, plates, re-ID, threat, the gather belt counts one per leg); the ids lists live only in the log/metric half. Proven against 7 real leaks pre-fix (the space-mismatch line carried both id lists into the prompt; the plate except arm shipped str(e); the rev-7 threat line named the ledger item). 8 pins (TestPromptHygiene, BANNED_IN_PROMPT, MAX_PROMPT_LINE=48). Gates on the shipped tree: unit -n auto → 1 failed, 28609 passed (sole failure the known systemctl env-fail, identity banked; 28600→28609 via 9 new pins); contracts → 646 passed; gen-ai-contract.py --check current; integration live :5433/:6380 → face-provenance + vlm suites 43 passed after the third-twin repair (commit A re-passed the full tier standalone: 0 failures); typecheck clean. Companion erratum (owner rule "keep unrelated fixes in their own commits"): the pushed stage slice 3a8e2184 rode the integration pub/sub batch_id matching fix inside the feature commit — that hygiene fix belonged in its own commit; from here the split is enforced at staging time (this session's A/B split: enrollment provenance vs prompt hygiene, git stash --keep-index + a --fixup rebase folded the missed conftest twin into A pre-push). SYNTHETIC VERDICT-CHANGING CASES CLOSED [V]: five labeled sets (specialist-context-cases, aggregate metrics only, no imagery — D10): normal/resident_arrival_known_face + suspicious/casing_unknown_face (same scene shape, benign known face vs suspicious unknown), normal/vehicle_parking_household_plate + suspicious/vehicle_visit_unknown_plate (household vs unknown plate), suspicious/night_approach_tiny_face (the F12 pin: a 24-px crop at scrfd 0.82 reads not identifiable, never unknown). The pairs differ ONLY in the specialist line. The loader (eval_store._render_specialist_outputs) renders each set's specialist_context spec through the SHIPPED classify_face_outcome + text builders — the F12 clause is a property of the corpus, not of test copy; a knob flip (FACE_MIN_SIZE_PX=200) flips the committed 120-px case from unknown to not identifiable, pinned. Absent specialist within a declared block ⇒ "unavailable: specialist did not run" for all three keys (never silently empty); absent block ⇒ {} (pre-rev-6 shape preserved, pinned); malformed spec degrades ONE key loudly and the item still loads; the loader deliberately does not call _unavailable_line (corpus loading is not a field failure — no live Prometheus increment). Corpus 408→413 (benign 134→136), count pins moved. 9 new pins in TestSyntheticSpecialistContext; test_eval_store.py 43 passed; evaluation dir 200 passed 3 skipped. S-3 hedging report [?]: the cases are labeled for the Phase 2 bake-off to measure whether the VLM uses the context (and whether uncertain hedging shifts); no measured answer yet — deferred to the 2.2 runs, stated here so the deferral is not silent. LIVE PER-BATCH BUDGET CLOSED [V] (the plan's :153): agent-gpu run --name s4-vlm --image ai-vlm:sm103-v12 --vram 14 --port 8098 --mount models:/models (Qwen3VL-4B default, SLEEP_IDLE_SECONDS short), face legs registered through the DEPLOY load path (get_model_zoo() rows → sha256-pinned load_fn → _loaded_models; the two pinned ONNX copied to models/model-zoo/face-recognizer/, sha256 verified against the models.yml pins). Driver timed the SHIPPED collect_specialist_outputs per batch, public-domain stock frames, median of 5: 1-pick batches 0.041–0.100 s, the 4-key-frame ceiling batch (4 distinct camera/class pairs, faces present) median 0.412 s / max 0.514 s. One live assess through the SHIPPED VlmClient (enforcement probe + breaker + json_schema decode all live): 3.50 s wall, verdict confirmed, risk 0 ("person in a painting … no threat"); worst-case stage+assess 4.01 s against the 30 s S4 p95 bar. The container was agent-gpu rm-ed after (broker back to containers: []). Scope honesty: this is the STAGE budget the box asks for — the formal S4 p95 (including cold starts, sampled) closes on 24 GB-class hardware per F13/spec :375, and the wake-through-sleep check rides the owner's M1 run (:181). Sandbox driver env notes: MODEL_ZOO_PATH=$AGENT_GPU_DIR/models/model-zoo, dummy DATABASE_URL (settings validation only — the driver touches no DB), FOSCAM_BASE_PATH overridden to the frames' root for the assess leg only (the path guard still enforces). | this commit | | 1.4 static vlm residency set (rev 6) | Commit c271d5e7 (residency.py named sets + the entrypoint's move-not-delete prune). [V] code + every sandbox tier; [O] the A5500 live half — residency control is the REPOSITORY, not Triton load control (owner ruling F11; --model-control-mode=none unchanged, no explicit mode, no specialist wake hook) | 2026-09-26 | Mechanism (plan: "pick it and ledger it"): a named-set prune at entrypoint step 0d, not a separate repo path. ai/gateway/residency.py maps GATEWAY_MODEL_SET → a model-name set (resolve_active_set; default full = today's 14 = behavior-preserving) and apply_model_set MOVES excluded model dirs to ${TRITON_MODEL_REPO}.retired (move-not-delete: idempotent + restorable without a rebuild, foreign dirs left alone, stale dest cleared). Both --repository default and Triton's --model-repository read the SAME TRITON_MODEL_REPOSITORY (default /models/repository), so prune and scan can never target different trees. vlm set = ("yolo26","reid") (VLM_MODEL_BASE), + threat only when GATEWAY_ENABLE_THREAT truthy — the threat include/not-include call is 3b's, deferred there. Fatal on failure (review item 2): the entrypoint residency line has NO | | echoswallow (unlike cosmeticpatch_triton_configs.py) — a failed prune would leave retired models in the repo for Triton to scan, exactly what rev 6 forbids, so the container must stop. fullis the shipped default on purpose (this slice changes nobody's footprint): the nemotron pipeline still calls the enrichment Triton models and no CI tier boots real Triton;vlmis selected by 1.5 (PIPELINE_MODE) / 1.7 (A5500 bring-up). One source of truth (review item 1):main.py ALL_MODELSis nowlist(FULL_MODEL_SET)(was a hand-mirrored 14-list) +test_residency.test_full_set_is_main_apis_registryasserts the identity (not just the mirror), so the repo/healthdescribes and the repo the entrypoint prunes cannot drift. Env-first:.env.exampledeclaresGATEWAY_MODEL_SET=full+GATEWAY_ENABLE_THREAT=falseFIRST;docker-compose.prod.yml passes both with in-file interpolation defaults (${VAR:-full}/${VAR:-false} — an undeclared host var never reaches a container). | Task 5 (1.5) obligation (owner ruling, review item 2): 1.5 switches the GATEWAY_MODEL_SET default in BOTH docker-compose.prod.yml and .env.example to vlm in the SAME slice that makes PIPELINE_MODE default vlm, and adds a test that the two defaults AGREE — a deployment must never boot the vlm analyzer against a full-mode gateway (or vice versa). Recorded in test_gateway_model_set_compose.py's module docstring. full is deleted with R8 when the legacy pipeline goes. Task 5/6 follow-up (review item 3): backend/api/routes/model_management.py (module docstring ~:20 and _triton_ready ~:411) assumes the gateway root /health lists EVERY Triton name — true in full mode (it iterates the full registry and is the only surface reporting clip/clip_text/stgcn_action). In vlm mode the root payload lists only yolo26/reid(+threat), so the 11 retired names are reported nowhere and _triton_ready logs one "reported by no gateway health payload" drift warning per retired entry per poll — expected noise, NOT catalogue drift. Docstrings updated NOW with the residency caveat; the retired models get their real empty states ("not analyzed in VLM mode", R8: empty states, not deletions) in Task 6. /health itself is NOT false-degraded (it iterates ACTIVE_MODELS, so absent models are simply unlisted, never not_loaded). Gates: gateway suite uv run pytest ai/gateway/tests/ → 274 passed, 1 skipped; unit uv run pytest backend/tests/unit/ -n auto → 28,521 passed, 2 failed — identity 1 test_deploy_phases::test_skips_when_skip_build (the known systemctl env-fail from the 1.1 baseline), identity 2 test_clip_client.py::TestGlobalClientSingleton::test_reset_clip_client_clears_instance — a PARALLEL-only flake on clip_client's module-global _clip_client (an assert client1 is not client2 against a process-wide singleton shared across xdist workers' view of the module) — passes in isolation (1 passed) and serially (82 passed), and did NOT reproduce on the immediate -n auto re-run (1 failed, 28,522 passed — only the known env-fail). Unrelated to this slice: nothing here touches clip_client. Banked as a flake identity, not a regression. contracts -n0 --timeout=30 → 646 passed EXIT=0; gen-ai-contract.py --check → "AI contract is current" (the residency work touches no generated surface); integration (live Postgres :5433 + Redis :6380) → 4081 passed, 107 skipped, 2 xfailed, EXIT=0 (a first attempt aborted at 3185 errors when the sandbox's test containers exited mid-run — docker start + re-run gave the clean tier; failure identities, not counts, per rule); cd frontend && npm run typecheck clean. bash -n ai/gateway/entrypoint.sh clean. docker-compose.ghcr.yml untouched (1.2 precedent: ghcr stays out of Phase 1). prod ai-gateway healthcheck comment still reads "Triton loads 14 models" — left as-is (accurate in the shipped full default; 1.5's default-flip rewrites it). A5500 [O]: "the gateway serves the static vlm repository and no retired model appears in Triton's model index" — F3 stands (no arm64/sbsa tritonserver base here), so the live index proof is 1.7/owner-run; the prune logic is proven here against tmp trees. | this commit | | 1.5 PIPELINE_MODE, default vlm (spec §2:81-84) | Commit 4c0f12a1 (the setting + one factory at every analyzer seam; 2ea790bc later made the deployment actually reach the vlm client). CLOSED [V] — vlm is the shipped default in every place a DEPLOYMENT reads; legacy parses, is LOUD at startup, and is wired nowhere as a fallback; an unknown value RAISES (the never-silently-fallback rule) | 2026-09-26 | Setting: pipeline_mode: str = "vlm" in backend/core/config.py beside the nemotron* block, field_validator(mode="before") that lowercases/strips, raises ValueError on anything but vlm/legacy, and logs a WARNING naming the unsupported path when legacy is selected (spec rev 5: "not deployed, not measured, not a rollback target"). One factory, five seams (plan said three): backend/services/pipeline_factory.py::build_pipeline_analyzer holds the ONLY prod analyzer construction (lazy per-mode imports so neither mode pays the other's import closure). The plan's seams — pipeline_workers.py:799 constructor, api/dependencies.py get_nemotron_analyzer_dep, container.py analyzer_factory — plus a 5th the plan did not enumerate: batch_aggregator._process_fast_path's lazy builder (a real construction site git grep found; rewired, ledgered here as the plan-vs-repo note) — and container.py builds the enrichment kwargs ONLY in legacy mode. A structural source-scan test (test_pipeline_factory.py::TestNoDirectConstruction) fails if any of the four seam files gains a direct NemotronAnalyzer( call; git grep -n "NemotronAnalyzer(" -- backend/ \| grep -v tests → exit 1 (zero prod constructions). Honest vlm-mode seam surface (no second analysis path): VlmAnalyzer.analyze_detection_fast_path routes the single detection through its own batch gate (fast_path*{id}batch), andanalyze_batch_streamingyields the SAME StreamingProgress/Complete/Error vocabulary the SSE route json.dumpses — but where nemotron's streaming path papers a NULL score over withrisk_score or 50/"medium" (the S5-forbidden default-score lie), the vlm adapter yields a StreamingErrorEvent instead; pinned by test ("50" not in str(final)). P0.3 startup gate branches on the analyzer the container BUILDS (hasattr(analyzer, "\_constrained_enabled")= legacy, unchanged; elseVlmAnalyzer.\_get_client().\_probe_enforcement([])behindvlm_enforcement_probe_enabled) — the container singleton IS the mode decision materialized, so a per-subject pin that swaps the singleton is honored by construction; all 5 existing gate pins (incl. container.lookups == ["nemotron_analyzer"]) stay green. 1.4's executed ruling (ledger 1.4 "Task 5 obligation"): GATEWAY_MODEL_SETdefault flipsfull→vlmin BOTHdocker-compose.prod.ymland.env.examplein this one slice,PIPELINE_MODE=${PIPELINE_MODE:-vlm}added to the backend env, andtest_pipeline_mode_default_agrees_with_the_residency_default pins the two defaults AND the .env.example declarations agree ({PIPELINE_MODE: vlm, GATEWAY_MODEL_SET: vlm}). ai/gateway/residency.py's bare-module fallback (and the entrypoint echo's :-full) stay fullDELIBERATELY — the owner ruling named exactly the two files; compose always passes the var, so both fallbacks only bite a manual devpython -mrun; docstring rewritten to say exactly that and point at the agreement test. prod gateway healthcheck comment updated (14-modelfullworst-case start_period vs the shipped 2-modelvlmset). Binding rule 5 test-wire: integration conftest gains session-autousemock_vlm_enforces_grammar— the tier now boots in vlm mode, so the mock ai-vlm must pass the chat-shape probe exactly asmock_llm_enforces_grammardoes for the legacy mock; the patch target is theVlmClient.\_probe_enforcementMETHOD because the analyzer owns its client's construction (transport injection can't reach every client a test builds);legacy_wire stays the per-subject pin for tests whose subject IS legacy. | Gates (identity diffs, not counts): unit uv run pytest backend/tests/unit/ -n auto → 1 failed, 28,621 passed, 122 skipped, 8 xfailed — identity set IDENTICAL to the banked baseline's sole failure test_deploy_phases::test_skips_when_skip_build (the systemctl env-fail, item 14); +12 tests vs the 1.3b-banked run (28,609) = 11 new test_pipeline_factory.py (named for its subject so the check-integration-tests hook's same-stem rule passes) + the new compose-agreement test (one 1.4 test changed in place: declared-value full→vlm). Honest flake note: the FIRST post-flip run showed 3 failures — the known env-fail + test_batch_aggregator::test_process_fast_path_creates_analyzer (a REAL 1.5 test-wire break: the test patched the direct NemotronAnalyzer import the factory replaced — fixed at the new seam, patched build_pipeline_analyzer instead) + test_clip_client::test_get_clip_client_creates_instance (module-global singleton order flake of the kind banked in the 1.4 row — passes standalone 82/82 serially, did not reproduce). contracts -n0 --timeout=30 → 646 passed EXIT=0; gen-ai-contract.py --check → current (no generated surface touched). integration (live PG :5433 + Redis :6380, canonical TEST_* URLs) → first post-flip run 2 failed, 4079 passed, 107 skipped, 2 xfailed — both test-wire, fixed this slice: (1) test_pipeline_e2e::test_fast_path_high_priority_detection stubs nemotron_analyzer.httpx.AsyncClient and asserts is_fast_path=True (a column only nemotron's fast path writes) → a legacy-subject test under rule 5; legacy_wire broadened to also pin PIPELINE_MODE=legacy (the factory now routes it), fixture applied. (2) test_vlm_analyzer::TestScoredEventOnLiveSchema::test_scored_batch… failed assert 'high' == 'critical' — proven PRE-EXISTING: the same two-test pair fails identically on clean HEAD with 1.5 stashed; root cause is the @lru_cached get_severity_service(): test_system_api::test_update_severity_thresholds_persists drives the REAL route, which rebuilds the singleton at 25/55/85 and nothing resets it back, so any later analyzer ON THAT WORKER bands 85 high not critical — order-dependent, invisible pre-1.5 because the tier booted legacy analyzers. Fixed at the root in backend/tests/conftest.py::reset_settings_cache (the settings cache and the service built from it are one state; the route itself already pairs cache_clear with reset_severity_service — the test-safety net now does too). Second run → 4081 passed, 107 skipped, 2 xfailed, EXIT=0 — identity-identical to the 1.4-banked baseline (the two first-run failures are gone; the severity flake cannot recur: the root-conftest fix 42307080 rides this push). cd frontend && npm run typecheck → EXIT=0 (no frontend edits; verification type already rides the generated client). | this commit | | 1.6 the frontend (spec §4:196-201) | CLOSED [V] — every plan bullet shipped, four slices, and the null-lie is gone from every event surface the plan names: a NULL score renders NO level (the verdict badge), never a confident green "Low" | 2026-09-26 | cd frontend && npm run typecheck → EXIT=0; npx vitest run src/components/events → 38 files passed / 1 skipped, 1266 passed / 14 skipped, EXIT=0 (the skipped file is the pre-existing LinkPersonModal.integration.test.tsx, untouched here); the 1.6 new/changed suites EventVerificationSection + EventDetailModal + risk + severityColors + EventListView + MobileEventCard → 6 files, 307 passed, EXIT=0; FULL frontend tier re-run on the final head ca6d734c → 782 files passed / 3 skipped, 20,318 tests passed / 136 skipped, EXIT=0 (409.8 s; the 3 skipped files are pre-existing, none touched by 1.6); generated surfaces verified current, NOT hand-edited: uv run python scripts/generate-ws-types.py --check → "WebSocket types are current", gen-ai-contract.py --check → current, openapi/api.ts already carries verdict + the verification object from 1.1/1.3 and the 1.6 prerequisite → no regeneration needed | Three rulings that shaped the slice, each recorded rather than silently absorbed. (1) The plan names EventFilters for the verdict filter — that file is DEAD CODE (zero non-self imports), so the filter landed on the live surface FilterChips.tsx instead; recorded per the doc-vs-repo rule. (2) The plan's first box says "typecheck-red first … generated types regenerate" — nothing regenerated: the 1.1/1.3 surfaces had already put verification and verdict on the generated types (the WS schema carried verification natively since P0.4), so there was no typecheck red to write. The red lives in the BEHAVIOR, and it went red-first there (307 pins). (3) The vlm-mode signal for the retired-enrichment empty state is the event's own verification row — spec §4: "verification object, present on every vlm-mode event" + "Legacy events have no verification row", so the row IS the data-driven mode flag; no PIPELINE_MODE plumbing was added to the frontend (1.5's setting stays a backend deployment concern). The null-lie doctrine, where it actually bit: risk_score \|\| 0 renders a never-analyzed (or verification_failed, D11-NULL) event as a confident green Low badge — a reader who trusts it is told an unchecked event was checked and found harmless. src/utils/risk.ts gained resolveRiskLevel(level, score) (server-computed level WINS — it already carries SeverityService thresholds; score is the fallback; NULL/empty = no level, never 0) and riskSortKey/compareRiskSortKey (unverified ranks ABOVE every score worst-first — a broken verification is an incident, not a dismissal; the naive key(a)-key(b) on two Infinities yields NaN and scrambles the whole sort, so two unknowns compare EQUAL — pinned). Applied across the plan's named surfaces + their card twins: EventListView, EventTimeline, EventCard, MobileEventCard, TimeGroupedEvents, EventDetailModal, severityColors. The EventClusterCard case is the instructive one: 6 pins broke my first attempt because I recomputed the header from member events, but the producer (eventClustering.ts) publishes highestRiskScore/highestRiskLevel as the cluster's OWN contract and the tests override them — the lie lives in the PRODUCER's default (an all-unscored pile → (0,'low')), so the component gates on the producer's own scoredness condition (events.some(score != null)) and keeps the summary contract. Verdict badge: one owner common/VerdictBadge keyed on the VERDICT — the interim ActivityFeed chip keyed on risk_score === null was blind twice (a SCORED rejected event showed no chip; verification_failed's NULL score looked identical to never-analyzed). VERDICT_CHIP_FILTERS exports the filter vocabulary from the same LABELS table so chip and badge cannot drift spellings; the glance surface keeps its restraint (a confirmed event with a score shows only its risk badge — a green chip on every card is noise). The verdict filter needed a backend half: the verdict lives ONLY on event_verifications, never denormalized onto Event, so GET /events + /search gained an EXISTS/NOT-EXISTS filter applied to the BASE query (an unfiltered total above a filtered list is a lying count), 'none' as a first-class pseudo-value for never-verified (the first question an operator asks a fresh vlm deploy; the CHECK still refuses it as a STORED value — deliberate asymmetry, pinned), and the param is a Literal so a typo is a 422, never an empty list (an empty list reads as "no rejected events" — the same false all-clear 1.5's no-silent-fallback rule refuses for PIPELINE_MODE). Deferred, honestly named: AlertsPage.tsx/AlertCameraGroup.tsx still carry \|\| 0 sites — the plan names only EventTimeline/EventListView, and the alerts surfaces are a separate payload shape (flat alert rows, not events); not silently fixed, not silently skipped. R8 honored: nothing deleted — the retired enrichment panels gained an empty state, and model_management.py's retired-model docstrings from 1.4 point at exactly this pattern. | 677a40f6 (badge + filter), 1c575e21 (backend verdict-filter prerequisite), bcf1e253 (null-safe risk rendering, 13 files), ca6d734c (verification section + retired-enrichment empty state); CI reds from the branch's own 1.3 work greened in f75a7fab | | 1.7 A5500 bring-up - repo-side half (spec :482-500; the run is owner-run [O]) | Commit 8da6f2c8 (the precheck's VLM pair + the dated handout). DONE (repo-side) [V] - scripts/a5500_precheck.py converted from the legacy placeholder-LLM pair to the shipped serving-VLM set, TDD, and the dated handout exists; execution remains the owner's | 2026-09-27 | uv run pytest backend/tests/unit/scripts/test_a5500_precheck.py -q -> 48 passed; uv run python scripts/a5500_precheck.py --check-only (real tree) -> exit 1, 2 FAIL; uv run python scripts/a5500_precheck.py --out docs/superpowers/plans/2026-09-27-a5500-vlm-bringup-checklist.md --date 2026-09-27 -> handout written | Red-first: 29 of 48 failed against the P0.2 script (the four converted/new check groups), then 48/48. Real-tree verdict is the [V] prep review, and it changed shape from P0.2: the serving model is no longer what the A5500 lacks. 2 FAIL - gpu_assignment (GPU_YOLO26/CLIP/ENRICHMENT/ENRICHMENT_LIGHT=1 at .env.example:580-583 + GPU_AI_SERVICES=1 at :962), cuda_arch ('89' at :576, and the FAIL text now names ai-vlm, the build that consumes it). 3 PASS - vlm_model (the Q4_K_M + mmproj pair ships correct, :462-463), ai_vlm_mount (prod compose /vlm:/models:ro :253), vlm_model_env_passthrough (:265-266). 1 INFO - vlm_ctx_budget per-slot 16384 (32768/2) clears the ~12.2K worst-case vlm_assess (spec §2). 6 WARN, three of them findings worth naming: vlm_image - docker-compose.ghcr.yml has NO ai-vlm service at all, so the ghcr image path cannot serve the shipped mode (it never gained one; the P0.2 note about its hardcoded 30B MODEL_PATH at :172 survives inside the Serving VLM section, still true in kind); legacy_llm - prod compose's ai-llm has no profiles: block (:120), so --profile vlm up starts the retired 30B path ALONGSIDE ai-vlm and one A5500 cannot serve both (F10 keeps the service, not its deployment - the handout says keep it out of the up set); plus CDI gpu=all, the TMPDIR trap at :57, and 12 stale .pyc (flagged, not deleted, R8). How the checks are built matters: the ai-vlm read is block-scoped (service-block parse, not a flat line scan), because the legacy ai-llm legitimately mounts the 30B dir and derives MODEL_PATH from LLM_MODEL_PATH - a flat scan false-reddens the VLM checks on the retired service's own lines (pinned), and only a mount whose target is exactly /models counts, so the /models/model-zoo mounts are not misread as the weights mount (pinned). A MOUNT_RE shortest-host regex handles ${AI_MODELS_PATH:-/export/ai_models}, whose own :- colon breaks a naive .split(":"). Two bugs found in my own red suite, not in the green code: a profile-gated ai-llm case that replaced into a fixture with no ai-llm at all, and a .replace("CUDA_ARCHITECTURES=86", "=89") that blanked the key and produced the empty-value WARN instead of the 89 FAIL - both fixed in the test, each a silent-vacuous-pin class of error. 2026-09-25-a5500-bringup-checklist.md got a SUPERSEDED banner rather than deletion (R8: build empty states, not deletions) so an A5500 reader cannot land on Nano-4B instructions. The run itself is the owner's [O]: smoke-serve Qwen3-VL-4B and run the P0.3 enforcement probe BEFORE any event reaches the server - the ordering the handout states as mandatory and the precheck can only assert about the tree, never about the box. | git log --grep 'A5500 precheck serves the vlm mode' - the row rides its own commit; no hash can name itself (the 1.1 row's literal "this commit" is the same lesson already in this table) | | M1 review — the seven fixes (the null-lie, the provenance readers, the vlm wire, the prompt budget) | CLOSED [V] — the milestone's built-in code review (the goal file retires superpowers:/codex here), executed over the Phase 1 vlm path and turned into seven commits, each red-first, each gated. Scope honesty: this review is SELF-verified, not agent-verified — one parallel vlm-path agent's residency claim was disproved and is corrected at item 24 | 2026-09-27 | uv run pytest backend/tests/unit/ -n auto → 1 failed, 30,433 passed, 123 skipped, 8 xfailed (sole failure test_deploy_phases::test_skips_when_skip_build, the sanctioned systemctl env-fail, identity unchanged from the 1.1/1.3b baselines); uv run pytest backend/tests/contracts/ -n0 --timeout=30 → 646 passed; uv run python scripts/gen-ai-contract.py --check → "AI contract is current"; cd frontend && npm run typecheck → exit 0; per-slice npx vitest run src/... from frontend (8 suites 229 tests; search suites 111 passed / 24 pre-existing skips) | The review's shape: every finding was a rule that shipped with a READER that ignored it. Seven classes, all fixed at the reader, never at the caller, because a caller that forgets is the failure mode the rule exists for. ① c8050bac provenance (F11): match_face() gained model_id + the canonical outcome table — an untrusted probe (None or the sentinel) and a foreign-space row are both refused a number, and a gallery where a foreign row is the byte-better match no longer reports a match (skipped and counted). The face leg reads the belt off the LOADED handle inside the gallery seam (an unload race reads None → unavailable, never a guess); an uncomparable gallery degrades the whole specialist line instead of folding into "1 unknown face" (an uncomparable gallery is not an observation about a person); POST /face-events/match retired 410 Gone — the D-1 precedent applied to the face twin, with OpenAPI + generated TS in the same commit; the entities route threads the query's model_id into find_matching_entities, which could previously only return a permanently empty 200; and enrollment's two "no crop" arms were conflated by nullable columns — a zero-AREA bbox is corrupt data (raises), a detection with no bbox at all is the legitimate weak path (logged, used whole). ② 4bc16ebe the null-lie (D11) on the surfaces 1.6 did not name: utils/risk.ts's null-safe helpers had shipped with zero production adopters, so D11 was enforced only in its own unit tests while the live mappers still coalesced — DashboardPage's risk_score ?? 0 erased the nulls the P0.25 gauge guard then filtered on (dead code for every REST event; an unscored newest event read as "all clear", pinned red as data-risk-score="0"), useConnectionStatus folded invalid levels to low, and useTopEventsQuery/TopEventsCarousel — the surface whose job is "show me the worst" — buried never-verified events beside harmless ones (?? 0) and NaN'd on two unknowns (Infinity - Infinity). Now: nulls pass through, ranking goes through compareRiskSortKey, an unscored tile renders the verdict badge on a neutral border. ③ 2ea790bc the vlm CLIENT wire (the mode was nonfunctional end-to-end): compose set PIPELINE_MODE=vlm and passed NEMOTRON_URL/AI_GATEWAY_URL/YOLO26_URL but NO vlm client var ever reached the backend environment: block, and no compose file in the repo declares env_file: (verified: zero occurrences) — so Settings' dev default won inside a container that shares no network namespace with ai-vlm and ai_vlm_url stayed http://localhost:8098 = the backend's own loopback. Every vlm_assess → connection refused → §6's terminal rung → 100% of events verification_failed with a NULL score, while the breaker reported a MODEL outage that was a config gap. The same omission silently no-oped 1.5's per-build enforcement (vlm_required_build empty ⇒ the probe's build assertion is skipped), so after any llama-server/GGUF swap the client trusted whatever build answered — enforcement proven against one build laundering onto an unknown one, which is what S-2 exists to prevent. All six vars threaded ${VAR:-default}; AI_VLM_URL's fallback becomes the service DNS name; VLM_REQUIRED_BUILD keeps an EMPTY default ON PURPOSE (compose cannot know which build a local build produced — threading is the fix, the default is not). ④ 058ac533 SearchResultCard's two badges both read (risk_level as RiskLevel) \|\| 'low' on nullable fields — the search surface was not in 1.6's file list, so the lie survived there; the level now derives from the score (utils/risk is the single source), so no score = no level = "Unverified", and a scored result renders byte-identically. ⑤ 01080b51 the key-frame budget counted the wrong thing: select_key_frames deduped by detection_id and ranked (camera, class) PAIRS, but a still is a physical file and the detector emits one row per object over a SHARED file_path (detector_client:1184) — so one JPEG holding person+car+dog is three pairs on one file, and pair ranking handed that single image up to all four slots: the verifier saw one picture while the request claimed four, and genuinely different frames starved out. Worse, _key_frame_ids re-derived ids with {row["file_path"]: row["id"]} whose LAST write silently won, so key_frame_detection_ids (the UI's thumbnail resolver, spec §4) could name detection 13 when the model had been shown 11. Both now come from the selector's own picks and file_path is no longer a key on this path. The Hypothesis lesson: the property suite could not have caught this — its generator drew file_path from st.text(), a unique path per row, the one shape no real batch has; the generator now draws from a small pool so the collision class stays coverable. ⑥ bdb55335 a clip was being base64'd into the prompt: _image_parts trusted mimetypes.guess_type(...)[0] or "image/jpeg", so a .mp4 was labelled image/jpeg and embedded whole — and this is reachable BY DESIGN, because for video the detector sets detection_file_path = video_path (detector_client:1174), so every row of a video frame carries the clip and the selector offers it as the batch's one still. Two silent losses: an oversized container overflows one llama.cpp slot and the breaker reports a MODEL outage for a DATA problem (the 1.2 misdiagnosis from the other side), or the engine accepts it and "verifies" an event from bytes no image decoder ever read. Fixed by refusing on TYPE against the repo's own IMAGE_MIME_TYPES allowlist, with a byte guard before the read; VLM_MAX_IMAGE_BYTES landed in .env.example AND the backend block in the same commit (③'s lesson, and CLIENT_VARS now catches a knob that silently reads its code default). Honest about what it is NOT: the vlm path has no frame extractor — the detector's extracted JPEGs are deleted after detection (pipeline_workers:746), thumbnail_path is never populated for these rows, and ffmpeg is not in the backend image — so the refusal names the file and says extraction is what is missing, and the missing extractor is a named follow-up, not a buried one. ⑦ d1e279fd the prompt is FITTED to its slot: vlm_assess had no context budget at all — prompt_text() serialized context.detections whole, so a full batch went out at whatever size it came in; measured with the repo's own counter, ~61 tokens per detection row, so batch_max_detections=500 is ~30K text tokens against a 16,384-token slot. And the only context-window setting the backend carried was the WRONG one: nemotron_context_window derives from CTX_SIZE/PARALLEL, which the backend block mirrors from the LEGACY ai-llm service (262144/8 = 32,768/slot), while in vlm mode ai-llm is not running at all — ai-vlm starts at VLM_CTX_SIZE/VLM_PARALLEL (32768/2 = 16,384). Grading a vlm prompt against the legacy figure waves a 16.4K–32.8K prompt into a slot half its assumed size. So vlm_slot_count + vlm_context_window are new fields reading the vlm pair under separate aliases, same derivation rule, vlm scope. Truncation is visible and deterministic (the "log the clamp" doctrine): strongest-confidence rows survive on a TOTAL order (confidence, then lowest id — survivors never depend on arrival order, the same replay-equality rule as the key-frame selector), and the prompt says how many rows were omitted and that the survivors are what the attached frames were picked around — a model shown 60 of 500 rows and told nothing reads the gap as "no further activity", a lie by omission on the one channel §6 reserves for detector evidence. The image reservation is the documented ceiling (MAX_KEY_FRAMES × 1280 vision tokens, the selector's own constant), never a decode, so a prompt approved here cannot overflow on account of its images. record_prompt_truncated fires ONCE, at the wire: prompt_text runs twice per batch (wire + the analyzer's stored Event.llm_prompt), so a counter inside the renderer would double every event — the renderer returns a flag and assess owns the effect, and the stored prompt IS the sent prompt, one code path. | c8050bac (provenance readers + the face 410), 4bc16ebe (the null-lie on the surfaces 1.6 missed), 2ea790bc (the vlm client wire), 058ac533 (search card), 01080b51 (stills, not rows), bdb55335 (no clips, no unchecked frame), d1e279fd (the prompt budget + the vlm slot) — all pushed |

Phase 2 — Evaluation and the bake-off (plan: docs/superpowers/plans/2026-09-27-vss-phase2-evaluation-bakeoff.md)¶

| step | status | date | evidence | commit | | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | | 2.0 eval-store generation 2 (the corpus a replay can run against) | CLOSED [V] — gen-2 built and verified: 426 items, benign 141 / incident 285, 13 media-bearing, 5 with a rendered specialist_outputs block — the exact numbers the plan predicted from the loader run, now produced by the shipped builder. gen-1 is byte-identical (sha256 c56bbc43…1152 before = after): the generation, never an edit. | 2026-09-27 | TDD red first (ImportError: cannot import name 'build_gen2'), green at uv run pytest backend/tests/unit/evaluation/test_build_gen2.py backend/tests/unit/evaluation/test_eval_store.py -q -n0 → 52 passed (9 new + the existing 43, no existing test moved). The 9 pins: aggregates read back from the DB (not the in-memory list); the five 1.3b sets survive the freeze readable (SELECT … LIKE '%SC-%', all non-empty); zero-specialist-items aborts the build — gen-1's defect rebuilt is the one outcome 2.0 must not ship; a changed corpus into an existing generation refuses as one aggregate error; the same-input rebuild is idempotent (identical fingerprints → put_item's no-op); the store dir inside the checkout refuses before anything is read or written; missing corpus is FileNotFoundError; the per-item freeze re-pinned at the new call site. Driver: build_gen2($AGENT_GPU_DIR/out/eval-store/gen-2, corpus_dir='data/synthetic', stock_root=$AGENT_GPU_DIR/out/media/stock) printed the report above. The D10 guard earned its keep during its own TDD: the red run (before the guard existed) wrote a live labeled store into backend/tests/tmp-store/ — found, deleted the same minute, repo verified clean — the hazard made concrete, and the guard's test now asserts nothing is created at a refused path. | this row | | 2.1 the replay harness (2.1.1–2.1.5, 2.1.7) | CLOSED [V] — three new modules + 55 pins, every tier green. levels.py (one score→level helper, D-P2-3), s_metrics.py (S2/S3/S5 + a Wilson interval written in-repo), vlm_replay.py (the frozen corpus through the shipped VlmClient → EvalStore). The three honesty decisions the harness is made of: a refusal is verification_failed + NULL + the error class, never a default score; S3 is reported twice (all, excluding_zero_floor) because a floor of low cannot be failed; the report is aggregate-only (D10). | 2026-09-27 | TDD red first per module. Green at uv run pytest backend/tests/unit/evaluation/ -q -n0 → 260 passed, 3 skipped; full unit -n auto → 30,495 passed, 1 failed (the sanctioned test_deploy_phases::test_skips_when_skip_build systemctl env-fail); contracts -n0 --timeout=30 → 646 passed; scripts/gen-ai-contract.py --check → current (the replay consumes the contract). The pins that a convenient implementation would break: the stored specialist block reaches the request byte-identically (the replay's whole premise, rev 6); the module never imports vlm_specialists nor the legacy harness (AST, F10); _DEGRADABLE_ERRORS is set-equal to vlm_analyzer's ladder, so a bake-off cannot describe a different system than production; the run's model is candidate@commit (re.search(r"@(?:[0-9a-f]{7,40} | unknown)$")); --all-itemsrefuses citingimage_paths min_length=1rather than crashing per item — the same sentence the owner needs about the 408 label-only items (item 19). Wilson is checked against hand-computed closed-form values, not against scipy (re-checking the arithmetic with the library that did it pins the library, not the math), and scipy is transitive-only here — absent frompyproject.toml, present in uv tree— so a fixed bar's report must not rest on it. Commitsb3ef67d1(harness),635a58d9(the run names the endpoint it measured: 2.2 runs two candidates on two published ports, and resolving the URL once and building the client from that same value is the only way the report cannot name a URL the run did not call; an injected factory reportsinjected instead of guessing). | b3ef67d1, 635a58d9 | | 2.1.6 Live smoke on the GB300 | CLOSED [V] as the harness's end-to-end proof — and it produced four findings that 2.2 must read first. The harness ran: 13/13 items over the real wire, 13 rows stored, the ladder degraded the 6 refusals to NULL + the error class (no score fabricated), report aggregate-only. It does NOT close any S#: every one of the 7 verdicts came back risk_score=0, and the prose says why (finding C), so S2/S3 stay blocked — exactly as the plan's finding 3 already said they would. | 2026-09-27 | Serve: agent-gpu run --name vlm-smoke-216 --image ai-vlm:sm103-v12 --vram 14 --port 8098 --mount models:/models --env MODEL_PATH=/models/vlm/Qwen3VL-4B-Instruct-Q4_K_M.gguf --env MMPROJ_PATH=/models/vlm/mmproj-Qwen3VL-4B-Instruct-Q8_0.gguf --env MODEL_ALIAS=Qwen3VL-4B --env GPU_LAYERS=auto --env CTX_SIZE=32768 --env PARALLEL=2 --env PORT=8098 → admitted 14336 MiB, /health ok, /props b7972-e06088da0. Replay: ENVIRONMENT=test DATABASE_URL=… FOSCAM_BASE_PATH=$AGENT_GPU_DIR/out/media uv run python -m backend.evaluation.vlm_replay --store $AGENT_GPU_DIR/out/eval-store/gen-2 --candidate Qwen3VL-4B-Instruct-Q4_K_M@ai-vlm:sm103-v12 --vlm-url http://host.docker.internal:18100 --out …/reports/2.1.6-smoke.json → run dd6b8317…, commit pin 635a58d9, n=13, vlm_url_source: cli; confirmed 7 / verification_failed 6 (all 6 ConstrainedDecodingNotEnforced, broken_rows: []); latency median 8957 ms, p95/max 25256 ms — indicative only (F13). agent-gpu rm → containers: [], free 49062 MiB. | 635a58d9 | | ↳ 2.1.6 re-run on the fixed harness (ba823226) — and the two runs disagree | Both runs are honest; the disagreement is itself the finding. Same server, same image, same 13 items, same build b7972-e06088da0: run 1 (client-per-item) → confirmed 7 / verification_failed 6, all six ConstrainedDecodingNotEnforced, S3 all recall 0.625 [0.3057, 0.8632], refusal rate 0.46, latency median 8957 ms. Run 2 (one client per run) → confirmed 9 / uncertain 2 / verification_failed 2 (one ConstrainedDecodingNotEnforced, one VlmSchemaError), S3 all recall 0.875 [0.5291, 0.9776], refusal rate 0.15, latency median 6443 ms. The mechanism is finding A, not the model: with one client the probe runs on item 1 (stock:break_in_attempt — a scene that truncates at 400 tokens), fails once, succeeds on item 2, and is then cached ENFORCED for the rest of the run, so the truncation costs exactly the item it landed on (1 + 1 unrelated = the 2 refusals). s5.broken_rows: [] in both, so no refusal was ever folded into a score. What 2.2 must take from this: a per-candidate report off n=13 is dominated by WHERE the probe happened to fail, not by the candidate — the S3 intervals overlap so heavily that no ordering of candidates is supportable on this corpus, which is the plan's finding 3 restated in live numbers. And excluding_zero_floor is n=0, recall=None, wilson (0.0, 1.0) in both runs — the honest shape of a measurement that cannot be taken yet, printed rather than hidden. | 2026-09-27 | Same serve command as the row above (vlm-smoke-216c, admitted 14336 MiB, /health ok), same replay with --out …/reports/2.1.6-smoke-ba82322.json → run 896a4c2b…, commit pin ba823226, n=13, vlm_url_source: cli; latency p95/max 20705 ms — indicative only (F13). agent-gpu rm → agent-gpu ps containers: [], free 49062 MiB (the figure before any of today's runs). | ba823226 | | ↳ finding A — the enforcement probe's budget fabricates a verdict | CLOSED [V] — a shipped-path bug, not a harness one, repaired by finish_reason-aware triage that separates a cut-off reply from a server lie WITHOUT weakening fail-closed. The 6 refusals are NOT a model that ignores the grammar: replayed directly, all 6 replies carry finish_reason: length — the object was truncated mid-JSON. At max_tokens 1200 on the same server, 3 of the same 4 images echo the nonce (ENFORCED). The client's comment above _PROBE_MAX_TOKENS = 400 names this exact hazard — "a budget that truncates mid-object FABRICATES an IGNORED verdict (the const can sort last in the grammar)" — and the 400 was sized for the /completion probe, which emits the const only. On the multimodal shape the model writes summary/reasoning/description prose first, so 400 truncates on scenes with rich detail and the fail-closed ladder files it as ignored (the E5-class server lie). ~~Production hits this identically: _ASSESS_MAX_TOKENS = 700 with the same required prose fields.~~ [RETRACTED in this row's own assessment-leg half, below: that sentence was an inference from the probe leg, never a measurement — it is kept struck so the row shows which of its own claims were measured and which were not.] Severity for the M2 pick: an under-budgeted probe can read a correctly enforcing endpoint as not enforcing — a candidate could be eliminated for a budget. | 2026-09-27 | Measured with the shipped schema and the shipped image guard: at 400 — casing stop/echo ✓, delivery_driver stop/echo ✓, break_in_attempt length/✗, loitering length/✗, pet_activity length/✗, prowling length/✗; at 1200 — break_in_attempt stop/echo ✓, pet_activity stop/echo ✓, prowling stop/echo ✓, loitering still length (a verbosity tail, not a cliff).Repair (own change, own gate, red-first — the shipped-test pin verdict in {"ignored","inconclusive"} moved to == "ignored" and an explicit inconclusive-on-truncation pin replaced it, i.e. the pin moved WITH the reason this row named). A single-source truncated-stop vocabulary _TRUNCATED_STOPS = {length, max, limit, insufficient} + _is_length_truncated(stop) now live beside the probe that uses them; the client's _probe_enforcement reads the stop off the reply (_stop_reason_of: choice-level then body-level, None = "the server did not say" and is NEVER inferred as truncation) and triages in branch order — echoed const → enforced (the const answers the whole question, so a stop reason cannot answer it negatively); 200 + a truncated stop → _note_failure("vlm_probe_truncated") then raise inconclusive naming stop= and max_tokens=; a COMPLETE reply without the const → ignored (E5's evidence, unchanged). Fail-closed is byte-identical: truncation raises, the analyzer still maps it to verification_failed + NULL, the breaker still counts it, and assert client._enforced is None pins that an inconclusive caches nothing (a transient non-answer must not ossify). The CI CLI enforcement.py reuses the SAME helpers (single source) and its IGNORED now means one specific thing — a COMPLETE reply without the const — stated in its own docstring. The legacy /completion call site reads the new tuple's 3rd slot into _probe_stop and DELIBERATELY does not use it (F10: the repair does not extend the unsupported path). Real-pixels [V] proof, candidate A on the GB300 through agent-gpu (image ai-vlm:sm103-v12, /props build_info b7972-e06088da0, vram_actual_mib 8790 vs a --vram 14 declaration, agent-gpu rm'd after): the shipped chat-probe body (build_probe_schema + the client's own prompt sentence + one stock JPEG) driven at three budgets through the SHIPPED judgement helpers, not a re-implementation. A first proof run claimed the cliff "did NOT reproduce on the shipped shape" — that claim was itself wrong and is RETRACTED, and the way it was wrong is finding A's lesson applied to the proof itself: it drove the probe with the ANALYZER schema (4 scalar fields) while the shipped chat probe sends the full verdict WIRE schema (it adds a required description, a criteria array with minItems 1, a provenance object), a contract with far more required output. Re-measured with the shipped client's own _wire_schema(), the cliff is real and WORSE than a cliff — it is a COIN FLIP: repeated identical requests at the shipped 400 echo 3/4 on break_in_attempt (4/4 at 700; pet_activity 0/4 at 400 → 4/4 at 700; loitering needs ≈2000; casing/delivery_driver stable at 400). A scene at the cliff plus the gate's once-per-client cache means the whole run's verdict depends on which image happened to be first — that is finding G's substance, recorded as its own row with these numbers. What the retracted run DID validly prove still stands on its own terms: with the reply driven to truncation on purpose (budgets 100/150), all 8 truncated replies reclassify ignored → inconclusive and ignored appears ZERO times across the run — the triage neither forgives prose nor condemns a budget. Aggregate only, no imagery committed (D10): out/tmp/finda_triage.json (16 rows), out/tmp/probe_budget_cliff.json, out/tmp/probe_stability.json (4 reps/cell). Triage truth table checked as a pin: length/LENGTH/max/limit/insufficient → truncated; eos/truncated/None/""/other → not truncated (a real stop token named "truncated" is not inferred as truncation). Gate on the changed tree: unit -n auto 1 failed (the sanctioned systemctl env-fail), 30528 passed, 123 skipped, 8 xfailed; contracts -n0 --timeout=30 646 passed; integration on same-session connect-verified PG :5433 / Redis :6380 — targeted 108 passed, 22 skipped, full tier 4089 passed, 107 skipped, 2 xfailed; gen-ai-contract.py --check "AI contract is current"; four affected suites 347 passed, 3 skipped; new probe-CLI suite 9 pins green. The deferred sibling CLOSED the same day, and its premise MEASURED rather than inferred (the row's own "Production hits this identically" was an inference from the probe leg — so it was re-run, not trusted): raw assess-shaped requests at the shipped 700 over the six stock scenes → 3 of 6 come back finish_reason: length with an object that never closes. The repair lands as VlmTruncatedError — SUBCLASSED under VlmSchemaError, because the analyzer catches the base VlmClientError, so every existing mapping still answers verification_failed + NULL score (the ladder is neutral BY CONSTRUCTION, not by a new catch-site edit) — raised ONCE with no retry: the §6 retry re-asks the same body at the SAME 700 (only temperature changes), so it cannot close the object while burning breaker failures toward opening ai-vlm over a number we chose (finding B's contamination shape from a budget), and it records the cause as vlm_assess_truncated, never inflating the vlm_schema_invalid model-defect counter the M2 read uses. Real-pixels end-to-end through the SHIPPED client (probe OFF): the truncating scenes raise VlmTruncatedError once; a scene whose reply completes still returns a real verdict — and a well-formed-but-invalid reply that stopped NATURALLY keeps its VlmSchemaError + temp-0 retry (the triage forgives nothing that is actually a model defect). Gate: unit 30531 + the sanctioned env-fail, contracts 646, integration (connect-verified :5433/:6380) 76 on the vlm/degradation seams, mock-autospec ratchet green. Commits 6106ea98/c04396dd (probe leg) + this row's commit (assess leg). One measurement BOTH halves deliberately do NOT make: neither shipped budget is raised (_PROBE_MAX_TOKENS stays 400 / _ASSESS_MAX_TOKENS stays 700). The triage's whole point is that a budget no longer DECIDES a verdict, so raising one would have hidden finding A rather than answered it, and the re-run at the shipped budget is the row's first result; the sizing question itself, made urgent by finding G's cache-vs-cliff interaction, is an S4-touching trade-off the owner owns (open issue 28). | 6106ea98/7141cad0 | | ↳ finding B — the replay re-probed per item | FIXED the same day, harness-side. _enforced is deliberately per-instance (S-2: the proof must not launder onto another build), so a fresh client per item costs a fresh probe + /props per item — and 5 probe failures trip the shared ai-vlm breaker, which then answers VlmUnavailableError without I/O. The corpus could not see this because the two sets are disjoint (finding D), so 2.1.6 ran clean; it would have bitten 2.2's per-candidate runs — one candidate's probe failures opening the breaker the next candidate reads, so the report describes a breaker, not a model. Fix: run_replay calls the factory once and closes the client in a finally (one run is one endpoint at one build, which is the client's own documented lifetime). Honest limit: a failing probe still re-probes per item by design — S-1 pins that a transient INCONCLUSIVE must not ossify — so against an endpoint that genuinely does not enforce, 5 items still open the breaker and the rest of the rows say VlmUnavailableError. That is correct (fail closed, every row labelled with its real cause), but 2.2 must read the error classes before reading a refusal_rate as a model property. | 2026-09-27 | Red first: assert len(made) == 1 → AssertionError: a client per item re-probes per item (finding B). The old pin (closed == [1, 1], one close per item) was replaced, not kept, and its docstring says so. New pins: one client, closed exactly once, and closed even when an item raises a propagating bug. uv run pytest backend/tests/unit/evaluation/ -q -n0 → 261 passed, 3 skipped. | this row | | ↳ finding C — the stock set does not exercise the shipped assess prompt | OPEN, and it is what 2.2's numbers will measure. The stock loader freezes detections: [], zones: [], household: {}, specialist_outputs: {} — so the shipped _render_prompt sends "The detections below were produced by an object detector" over an empty list. The model's answer is schema-valid and self-consistent about that: criteria: [{"name": "Camera", "passed": true, …}] (its own schema's field names — the grammar was followed) and evidence "The provided image set contains no camera or camera-related object." So verdict: confirmed + risk_score: 0 is the honest reading of "confirm a detection that was never proposed": the 7 "confirmed" rows are the no-op case, not the VLM verifying a security event. A candidate bake-off run over these 13 answers "can this model emit the grammar", which is a floor, not a score. | 2026-09-27 | SELECT payload FROM items WHERE item_id='stock:casing' → the four empty fields; raw_response of the run's confirmed rows → the two quotes above (aggregate-safe: schema field names and the model's own prose about synthetic illustration style, no PII, no real-camera content — D10-clean). | this row | | ↳ finding D — the media-bearing set and the specialist-context set are DISJOINT | OPEN, owner-level, and the sharpest restatement of item 19. Of gen-2's 13 media-bearing items, 0 carry a rendered specialist_outputs block; of the 5 that do, 0 have media. So the 2.1.6 smoke exercises the wire but can never exercise the specialist prompt — and 1.3b's whole deferred question ("does the VLM hedge when specialist context is present?") stays unanswerable on the shipped wire until media exists for the synthetic items. That is the owner's synthetic-media item (19), not something Phase 2 can manufacture here. | 2026-09-27 | SELECT over items: 13 media-bearing all stock:; 5 with specialist_outputs all synthetic: with media_paths: []. | this row | | ↳ finding E — $AGENT_GPU_DIR/models had lost its traversal bit | FIXED in place, no code. First serve attempt: llama.cpp → gguf_init_from_file: failed to open GGUF file … (Permission denied); models/ was 750 while the container's user lands as other (mnt-probe showed /models owned by nobody nogroup inside). chmod 755 "$AGENT_GPU_DIR/models" — the traversal bit only, files unchanged at 644; model-zoo deliberately stays 750 (only in-sandbox reads need it). Re-probe read the GGUF magic; the same serve command then loaded. Cost: one failed admission + a container removed. | 2026-09-27 | agent-gpu run --name mnt-probe … --wait -- sh -c 'id; ls -ld /models' before (uid=1000(llama), /models nobody:nogroup, vlm unreadable) and after (magic G G U F). | this row | | 2.2.1 the tool-calling probe (scripts/vlm_probes/tool_calls.py) | CLOSED [V] — the line that keeps or closes R3, per candidate. Built like enforcement.py on the one rule that page exists to teach (S-1: the status code carries no support information): it asks for a report_token call whose only sensible source is a fresh per-arm uuid4, then judges the parsed body, never the status code. Arms permissive and strict, each with its own nonce so a cached reply cannot pass twice. Verdict stays in the plan's three words (SUPPORTED / IGNORED / ERROR) so 2.2.5 prints one comparable line per candidate; the plan's second question — did the required token argument survive the schema — rides in required_arg_honoured, and the gate (exit 0 only on a call whose argument arrived) lives in the exit code, not a fourth verdict. A 5xx is ERROR, never IGNORED (that would be a finding the server never gave); --expect-build refuses before any completion request (S-2). | 2026-09-27 | TDD red first. 17 judgement pins run against httpx.MockTransport (no GPU) — the same seam test_p03_constrained_verdict.py uses — uv run pytest backend/tests/unit/scripts/test_vlm_tool_calls_probe.py -q -n0 → 17 passed. The pins a convenient implementation would break: a 200-with-prose is IGNORED and never a pass (the E5 shape generalized); a 5xx is ERROR with required_arg_honoured: null, never IGNORED; a call whose argument/name/nonce is wrong is visible as REQUIRED_ARG_DROPPED (the arm detail), not rounded up to SUPPORTED; the arms differ only by strict (both carry required: ["token"], both temperature 0.0); a build mismatch touches only /props (hits == ["/props"]); the verdict is always one of the three words. --image attaches a synthetic data-URI still (never a remote URL — SSRF + nondeterminism, the s2_multimodal_schema.py rule). ruff/format/mypy clean, gated from the repo root. | e673b671 | | 2.2.2 candidate A — Qwen3-VL-4B-Instruct Q4_K_M (2.49 GB + 0.45 GB mmproj) | CLOSED [V] — the spec's four lines, all measured on the GB300 through agent-gpu, image ai-vlm:sm103-v12 (build b7972-e06088da0). (1) S-metrics on gen-2's 13 media-bearing items (this run doubles as the 2.1.6 re-run, same candidate, same command): S2 false-positive 0 / n=5, Wilson [0.0, 0.4345]; S3 all recall 0.875, 7 hits / 0 miss / 1 refused / n=8, Wilson [0.5291, 0.9776], excluding_zero_floor n=0 (the honest empty shape); verdict mix confirmed 9 / uncertain 2 / verification_failed 2; S5 refusals 2/13 = 0.154. (2) tool probe: SUPPORTED, both arms SUPPORTED, required_arg_honoured: true, multimodal true, exit 0. (3) long-context KV from the engine's own log: 4608 MiB (16384 cells × 36 layers × 2 seqs, K f16 2304 + V f16 2304) at CTX_SIZE 32768 / PARALLEL 2; model buffers 2375.91 CUDA + 304.28 CPU, compute 301.75 CUDA + 57.02 host, mmproj 432.93, projected 7285 of 48379 MiB. (4) license apache-2.0, no gating; model native context_length 262144. | 2026-09-27 | Serve (--vram 14 = 14336 MiB admitted; the engine's own fit line says it needs 7285 MiB of 48379 free, so the declaration is headroom, not a squeeze): agent-gpu run --name vlm-cand-a --image ai-vlm:sm103-v12 --vram 14 --port 8098 --mount models:/models --env MODEL_PATH=/models/vlm/Qwen3VL-4B-Instruct-Q4_K_M.gguf --env MMPROJ_PATH=/models/vlm/mmproj-Qwen3VL-4B-Instruct-Q8_0.gguf --env GPU_LAYERS=auto --env CTX_SIZE=32768 --env PARALLEL=2 --env PORT=8098 → http://host.docker.internal:18100. Replay run 896a4c2b, commit pin ba823226, vlm_url_source: cli, latency median 6443 / p95 20705 ms (indicative only, F13 — S1/S4 close on 24 GB hardware). Probe verdict: SUPPORTED verbatim both arms. agent-gpu rm → containers: []. S2/S3 rest on n=5 and n=8 stock items and are not the fixed-bar verdict — finding C says the stock confirmed rows are the no-op (empty detections) case, so this is a floor on "can it emit the grammar", never a claim the 5 %/90 % bars are met. | run 896a4c2b; probe/serve this session | | 2.2.3 candidate B — Nemotron-Nano-12B-v2-VL Q4_K_M (7.50 GB + 1.69 GB BF16 mmproj) | CLOSED [V] — fits under the cap; NOT a VRAM squeeze. Image ai-vlm:sm103-b11090 (build b11090-b1c2863e2), the llama.cpp bump spec :157-158 requires for this model. The plan made "cannot fit" the named risk; the measurement refuses it: vram_actual_mib 10118 against a 40960 broker cap (declared --vram 20, honest headroom over the ~8.5 GB real load), engine's own projected to use 7998 MiB of 47969 free. Four lines. (1) replay config-matched to A (CTX 32768 / PARALLEL 2): S2 0 / n=5 [0.0, 0.4345]; S3 all 0.875, 7/0/1, n=8, [0.5291, 0.9776] — identical to A, and the intervals overlap so heavily that no candidate ordering is supportable on n=13 (plan finding 3 in live numbers); the verdict mix differs — B answers rejected 11 / uncertain 1 / verification_failed 1 where A leans confirmed — exactly what the report prints beside the bars rather than flatten into the single recall figure; S5 refusals 1/13 = 0.077. (2) tool probe: SUPPORTED, both arms, arg honoured, multimodal, exit 0. (3) long-context KV: 768 MiB (16384 cells × 6 layers × 2 seqs) — B is a hybrid nemotron_h (63 layers, only 6 carry KV), so ~6× cheaper per token than A's 4608 MiB at the same ctx; buffers 6783.89 CUDA + 362.81 CPU, compute 158.82 CUDA, mmproj worst-case 1649.35. (4) license other / nvidia-open-model-license (a real gating term, not apache-2.0); native context_length 1048576 (1M). | 2026-09-27 | Serve: agent-gpu run --name vlm-cand-b --image ai-vlm:sm103-b11090 --vram 20 --port 8098 --mount models:/models --env MODEL_PATH=/models/vlm/NVIDIA-Nemotron-Nano-12B-v2-VL-Q4_K_M.gguf --env MMPROJ_PATH=/models/vlm/NVIDIA-Nemotron-Nano-12B-v2-VL-BF16-mmproj.gguf --env GPU_LAYERS=auto --env CTX_SIZE=32768 --env PARALLEL=2 --env PORT=8098; the CMD has no verbosity knob so the KV line was read from a relaunch mirroring the CMD with -lv 4. Replay run 4e02a70e, commit pin 390dd640, latency median 6234 / p95 14558 ms (indicative only, F13). Enforcement corroboration: the replay logged one ConstrainedDecodingNotEnforced on break_in_attempt — the same item finding A shows truncates at 400 tokens — so before trusting it, the image-free enforcement.py --expect-build b11090 was run three times: ENFORCED, exit 0, all three. A genuinely non-enforcing build refuses every item; one refusal among 12 passes is finding A's truncation class, verified, not assumed. First run_replay needed PYTHONPATH=. (module-path, harness-correct — main() is a CLI). agent-gpu rm → containers: []. | run 4e02a70e; probe/serve this session |

| 2.2.4 candidate C — Qwen3-VL-8B-Instruct Q4K_M (5.03 GB + 0.75 GB mmproj) | CLOSED [V] — the plan's BLOCKED assumption is SUPERSEDED by measurement, and the supersession is recorded rather than quietly enjoyed. D-P2-4 rested on cas-bridge.xethub.hf.co → 403. Re-tested rather than reused: that host answers, and its 403 is CloudFront's own MissingKey body ("Missing Key-Pair-Id query parameter or cookie value") — a signed-URL requirement, not a sandbox network block. HF's current resolve/ redirect for these files no longer points there: it lands on us.aws.cdn.hf.co, which serves public files without a signed key (HTTP 206 on a range read). Combined with the ungated official Qwen/Qwen3-VL-8B-Instruct-GGUF carrying Q4_K_M 5.03 GB + mmproj Q8_0 0.75 GB (5.78 GB — less than B's already-running 8.6 GB), 35 G free on the share. Fetched, served, measured — no new code. Image ai-vlm:sm103-v12 (build b7972-e06088da0), config-matched to A/B (CTX 32768 / PARALLEL 2). (1) S2 0 / n=5 [0.0, 0.4345]; S3 all 1.0, 8/0/0, n=8, [0.6756, 1.0], excluding_zero_floor n=0; mix confirmed 10 / uncertain 3 / failed 0; S5 refusals 0/13 — the only clean run of the three. (2) tool probe: SUPPORTED, both arms, arg honoured, multimodal, exit 0. (3) KV 4608 MiB (16384 cells × 36 layers × 2 seqs) — same shape as A: 8B shares the 36-KV-layer geometry, so the larger model buys no KV relief; buffers 4455.34 CUDA + 333.84 CPU, compute 312.75 CUDA + 72.02 host, projected 9376 MiB of 48259 free; broker vram_actual_mib 11216 vs 16384 declared. (4) license apache-2.0 (HF repo tag) — the downloaded GGUF header carries general.name and qwen3vl.context_length 262144 but NO general.license key, so the quant's own metadata does not attest its license: the repo tag is the source and a pin on the file alone would be a weaker provenance than A's; ungated. | 2026-09-27 | Fetch: curl -sSL -C - --retry 5 of both files from huggingface.co/Qwen/Qwen3-VL-8B-Instruct-GGUF/resolve/main/<file> into $AGENT_GPU_DIR/models/vlm/ (weights never in git, D10; share had 35 G free) → 5027784800 B + 752289728 B. Finding-E class, again, one layer deeper: the fetched files landed mode 640, so the serve failed gguf_init_from_file: … (Permission denied) — the container user is uid 1000 in the _other class (A/B's files were already 644). chmod 644 on the two files (read bit only), relaunch loaded. Serve: agent-gpu run --name vlm-cand-c --image ai-vlm:sm103-v12 --vram 16 --port 8098 --mount models:/models --env MODEL_PATH=/models/vlm/Qwen3VL-8B-Instruct-Q4_K_M.gguf --env MMPROJ_PATH=/models/vlm/mmproj-Qwen3VL-8B-Instruct-Q8_0.gguf --env GPU_LAYERS=auto --env CTX_SIZE=32768 --env PARALLEL=2 --env PORT=8098. Replay run 5a8a714e, commit pin e673b671, latency median 7487 / p95 10821 ms (indicative only, F13). Probe --expect-build b7972 --image → SUPPORTED both arms, exit 0. agent-gpu rm → containers: []. S2/S3 rest on n=5/n=8 stock items and are not a bar verdict (finding C). | run 5a8a714e; fetch/serve this session | | ↳ finding F — a fetched weight needs its read bit, and its header may not carry its license | TWO SMALL TRAPS, both found by doing the thing rather than trusting the plan. (a) Files fetched into $AGENT_GPU_DIR/models/vlm/ arrive mode 640; ai/vlm runs as uid 1000 llama, which is the other class on a bind-mounted root, so the serve dies Permission denied on a file the host can read. Finding E fixed the directory's traversal bit; this is the same class one level down, on the file's read bit — worth remembering for any future weight drop, including the owner's synthetic-media or Cosmos weights. (b) A GGUF quant's header is not a reliable license source: the 4B file carries general.license = apache-2.0, the 8B file carries no license key at all — so "license and gating" as a per-candidate line cannot be read from the file alone for every candidate. The honest form is license-from-the-source-repo plus the header's own claim when present, and a report that says which of the two it used. | 2026-09-27 | (a) ls -l showed 640 before / 644 after; container log verbatim gguf_init_from_file: failed to open GGUF file '/models/vlm/Qwen3VL-8B-Instruct-Q4_K_M.gguf' (Permission denied); the same serve command loaded after chmod 644. (b) GGUF header KV parse over both local files (no deps): 4B → {general.name, general.license: 'apache-2.0', qwen3vl.context_length: 262144}; 8B → {general.name, qwen3vl.context_length: 262144} — no general.license. Repo metadata license: apache-2.0, gated: False. | this row | | ↳ finding G — the enforcement gate caches once per client, and its probe can sit ON a budget cliff | OPEN, owner-level, and larger than finding A's triage — it decides what a probe PROVES. S-1 says only ENFORCED is cached, so _enforced=True is set once per client and every later item trusts it; finding A's triage makes a truncated reply refuse to score, which is correct and also makes the FIRST IMAGE'S budget the run's gate. Measured on candidate A: at the shipped 400 the chat probe is not cleanly enforced nor cleanly truncated on break_in_attempt — 3 of 4 identical requests echo the const, 1 truncates (4/4 at 700). pet_activity is a deterministic 0/4 at 400 and 4/4 at 700; loitering needs ≈2000; casing/delivery_driver hold at 400. So one replay's ENFORCED can rest on which image the store yielded first, and a candidate can be eliminated because its first frame is verbose. What this is NOT: not a reason to weaken fail-closed (an UNMEASURED reply must still refuse to score, finding A), and not evidence candidate A fails — the same endpoint enforces reliably once the budget clears the scene. The three candidate runs in 2.2.2-2.2.4 were each ONE client per run (finding B's fix) and all three answered the enforcement gate, so their S2/S3 numbers stand; what is now in question is the WORD ENFORCED as a per-endpoint property rather than a per-endpoint-per-scene-per-budget one. The three 2.2 runs keep their numbers, honestly bounded: their refusal counts are A 2/13, B 1/13, C 0/13 (each row's own S5 line), so the bars were computed on the items that answered — but a refusal here is the gate declining to trust the endpoint at all, so the counts are a budget measurement wearing a model's clothes. Owner question, deliberately not self-resolved — it is a D#/S#-adjacent trade-off (a larger probe budget spends the latency and S4 wall that the probe buys back). Options, with their cost stated: (1) raise _PROBE_MAX_TOKENS (measured need: 700 clears 4 of 6 here, loitering ≈2000); (2) probe with a MINIMAL probe-only schema instead of the full verdict wire schema — the CI gate already proves enforcement with 4 scalar fields, so requiring the model's whole verdict prose to prove a grammar is paying output cost for evidence the probe does not use; (3) probe once per (endpoint, build) rather than once per client-image intersection, which is what S-2's own wording is about; (4) leave it and treat ENFORCED as "enforced on the scene that happened to be first", which the row here would then say out loud in the report. My read is (2) with (1) as its enabler, because it removes the cliff rather than buying it back with latency — but that is a probe-contract change and the owner owns it. See open issue 28. | 2026-09-27 | out/tmp/probe_budget_cliff.py (shipped wire schema + nonce const, temp 0, budget ladder 400/700/1000/1400/2000 over the six stock scenes) and out/tmp/probe_stability.py (same body, n=4 per cell) against candidate A served through agent-gpu (ai-vlm:sm103-v12, build_info b7972-e06088da0, --vram 14, vram_actual_mib 8790, agent-gpu rm'd after). Echo@400: break_in_attempt 3/4, casing 4/4, delivery_driver 4/4, loitering 0/4, pet_activity 0/4. First-echo budget: break_in_attempt/casing/delivery_driver ≤400, pet_activity/prowling ≈1000, loitering ≈2000. Unstable cell: break_in_attempt@400 only. End-to-end through the SHIPPED client with the probe ON: break_in_attempt, loitering, pet_activity, prowling → probe_inconclusive; casing → the assess leg's VlmTruncatedError; and the 6th refused WITHOUT I/O by the now-open breaker. That last one is not a probe verdict and is labelled as such: the per-scene breaker reset in the driver did not work, because a client captures its breaker instance at construction, so five budget-caused failures opened the shared ai-vlm breaker — finding B's exact mechanism, rediscovered inside my own driver, which is how I know the label is honest. The consequence stands either way: budget-caused failures are indistinguishable to the breaker from model-caused ones, so a too-small probe budget can cascade a whole corpus into refusals. Schema diff that explains the whole gap (uv run python, in-repo imports): analyzer schema requires 4 scalar fields; the verdict WIRE schema the client probe actually sends requires verdict,risk_score,summary,reasoning,description,criteria[],provenance{engine,model_id}. Aggregate only; stock imagery, nothing committed (D10). POST-FIX re-run, same endpoint, same six scenes, one client, NO breaker reset (the real shape finding B established): breaker_open_after false, any_no_io_refusal false in BOTH arms — probe ON: 4×probe_inconclusive + VlmTruncatedError + one real verdict(rejected); probe OFF: 5×VlmTruncatedError + verdict(uncertain). Every scene answers with its OWN cause and the whole-corpus blanket refusal is gone; the enforcement cliff itself still refuses 5/6 at the shipped budgets, exactly as this row says it should until the owner picks from the three options. out/tmp/post_fix.py. | 7141cad0 | | 2.2.4 candidate D — Cosmos-Reason2-8B | BLOCKED — two independent blockers, neither resolved here (D-P2-4: BLOCKED, never dropped). (1) nvidia/Cosmos-Reason2-8B is gated: auto, license other — the weights require an accepted HuggingFace account before they are downloadable; the sandbox credential is not that account's and inventing one is not in scope. (2) No GGUF quant and no vLLM build for this GPU: upstream ships 17.5 GB of BF16 safetensors (measured via the model API, no download), and spec :281-282 already frames Cosmos as "our own vLLM (BF16), as a quality reference only; a consumer tier would need a quantized build" — ai/ has no vLLM serving path for sm103. The one thing that unblocks it: the owner placing a weights directory under $AGENT_GPU_DIR/models/vlm/ (or an accepted HF token) and a vLLM build for sm_103 — after which the report row fills in with no new harness code, because the replay is candidate-agnostic by construction. | 2026-09-27 | curl -s https://huggingface.co/api/models/nvidia/Cosmos-Reason2-8B → gated: "auto", cardData.license: "other", safetensors sum 17.5 GB (blobs=true, sizes only). Listing page reachable (http=200), so the gate is the blocker, not the network. Contrast recorded honestly: the plan's BLOCKED rationale for C and D was cas-bridge.xethub.hf.co → 403, and re-testing showed that 403 is a signed-URL requirement on a host that is otherwise reachable from here, not a network block — which is precisely why it was never D's real blocker either (D is gated, so it cannot obtain a public signed URL at all). The assumption was tested rather than reused; that test is what turned C from BLOCKED to CLOSED. | this row | | 2.2.5 / 2.2.6 the bake-off report, and its explicit non-claims | CLOSED [V] — docs/plans/2026-09-27-vss-phase2-bakeoff-report.md: the spec's four lines (S1–S5 + uncertain rate; the tool probe; long-context KV cost; license and gating) as one column per candidate, A/B/C measured, D BLOCKED, aggregate-only (D10). §2.2.6's non-claims are a numbered section, not a hedge: no model pick (D5 — M2 is the owner's), no S1/S4 claim (F13 — indicative latency labelled, 2.3 is the gate), S-3's hedging question NOT restated as answered (the 0.154 / 0.077 / 0.231 uncertain spread is its first measurement, and finding D shows the deferred question still cannot be asked on a corpus with no specialist context), no bar verdict printed (F14's 5 %/90 % appear as bar_pct inside the report JSON, beside the verdict mix, never against a silently-reset bar). Three findings the report leans on that only the comparison made visible: (a) A and B tie on S3 while answering opposite ways (A confirmed 9/13, B rejected 11/13) because every scored answer clears the stock incidents' low floor — the spec's §:276-279 pattern, and the mix is the only line that separates them at all; (b) the per-item table shows break_in_attempt is item 1 and is exactly the item A and B refused and C answered — finding A's budget artifact at the probe boundary, with B independently verified ENFORCED 3/3; (c) the KV line is the one difference that survives the corpus noise because it is a log reading, not a behaviour measurement (B 768 MiB vs A/C 4608 MiB at identical ctx, 6 KV layers vs 36). | 2026-09-27 | Read side by side: the three report JSONs plus SELECT item_id,verdict,risk_score FROM results WHERE run_id=? per run — all three runs replay the same 13 items in the same order, so the comparison is per-item, not just per-rate. git diff ba823226..e673b671 -- backend/ → empty: the harness that produced all three is the same code, which is what makes the columns comparable. Spec read for the four lines: §:284-291; S-definitions :73-77. Bars read from the reports' own bar_pct: 5.0 / 90.0, never restated as passes. | this commit |

| 2.3 hardware matrix on Brev — repo-side half only | CLOSED [V] as to the repo side; the RUN is owner-run [O]. Shipped docs/superpowers/plans/2026-09-27-brev-hardware-matrix-checklist.md: per tier (A10G 24 GB sm_86, L4 24 GB sm_89, RTX PRO 4500 32 GB sm_120 [A], T4 16 GB) the nvidia-smi --query-gpu=name,compute_cap,memory.total confirmation before trusting a number (spec :455; the risk table :587 names the failure mode — "a Brev VM's GPU differs from its label"), the real build-arg site (ai/vlm/Dockerfile:64 → -DCMAKE_CUDA_ARCHITECTURES) called out against .env.example:598 shipping 89 (an sm_86 box silently builds the wrong binary if nobody edits it), the serve/replay command shapes with the commit pin, what to read for S1 (peak with detector + specialists + VLM resident, GPU_LAYERS=auto — an offloaded serve is not a passing serve) and S4 (p95 including cold starts, so the replay's per-item block is necessary but not sufficient). 2.3.2: the NVFP4 question written as a reading task with its two named traps (RTVI_VLM_MODEL_PATH_ALLOWLIST's git: form per 04:74-75; the loader branch list at 04:54) — it asserts nothing and predicts no log line. Two honesty sections: the bake-off's projected figures are one container's floor, not S1; and the T4 "does not fit" line is arithmetic, not a measurement, which is why the tier exists. | 2026-09-27 | Commands checked against the repo, not invented: grep CUDA_ARCHITECTURES ai/vlm/Dockerfile → :64 ARG, threaded by the RUN at :66-70; .env.example:598 = 89; the replay's own CLI (--store/--candidate/--vlm-url/--out) and the two probes (--url --expect-build) are the shipped ones; PYTHONPATH=. required to invoke backend/evaluation/vlm_replay.py by path (learned honestly on candidate B's first replay). The env line the checklist ships was measured, not copied from the ledger: the replay opens no database — it ran to a written report against a copied eval.sqlite, a dead endpoint and no Postgres listening at all — yet get_settings() refuses to construct without a DATABASE_URL, and refuses a weak password unless ENVIRONMENT names a non-prod env, so the checklist carries a password-less placeholder plus that reason (1.3b's "dummy DATABASE_URL (settings validation only)" note, now proven rather than asserted). No Brev VM started, nothing priced, no S1/S4 number claimed — Brev spend is a stop-and-ask (open-issue 11), so the matrix runs when the owner runs it. The checklist also carries the honest scope sentence so nobody travels to a Brev VM to find the same 13 items: a tier's S1/S4 are its real contribution (they never depended on the corpus), while its S2/S3 stay corpus-blocked (item 19) — media for the 408 labeled synthetic items is the unblocking action, and it is not on a Brev VM. | this commit |

Open issues & owner-decision queue¶

1. G0 spec-vs-sandbox deltas (row 1, E4/E6/E9/E10) — recorded, no spec edit; folded into the G0 plan's step recipes.
2. F1 — runner build repair. RULING 2026-09-24: owner says repaired → CONFIRMED REPAIRED. Closing evidence, same day: fresh-layer non-cached builds ran to completion — agent-gpu images shows BOTH localhost/agent-vss1/ai-vlm:sm103 (3,588,219,493 B) and the fresh-layer ai-vlm:sm103-b11090 (b11090 clone+compile, the exact class that used to panic). Serve proof: agent-gpu run --name img-serve --image ai-vlm:sm103 --vram 12 --port 8080 --mount models:/models --mount out:/out → /health 200 in ~20 s, /props build_info b7972-e06088da0, model Qwen3VL-4B [V]; agent-gpu rm'd after. Found-and-fixed en route: the image runs USER llama (uid 1000) and models/ was mode-700 → GGUF open Permission denied; owner-chmod of the mount-root traversal (models/, models/vlm/ → 755; files already world-readable) — the broker's own-token mount is separate and untouched. Run-jobs served fine earlier because they ran as the broker default user. Unblocked: the ai-vlm:sm103 image path (G0.2's sanctioned-build caveat retired) and Phase 1's 1.2 compose wiring.
3. F3 — G0.3 vlm-mode GPU stack. RULING 2026-09-24: N/A on GB300, step closed. The step built the mode where the VLM borrows the GPU by stopping the other GPU models (Florence/enrichment under Triton) — needed on the 3090 box where memory was the fight. On this GB300 the spec's own rev-4 figure (~47.9 GiB ours) makes that dance pointless, no arm64/sbsa tritonserver base exists in any repo Dockerfile (26.01-py3 is amd64), and the explicit-mode switch would change a 501-asserted public surface (model_management.py tests assert it). Nothing built; no code to retire (R8 untouched). This ruling closes G0's last open step.
4. F4 — legacy-path fail-closed semantics (spec 0.3). RULING 2026-09-24: APPROVED (owner: "yes"). Still zero code — spec-0.3 work belongs to Phase 0's plan (next phase, one-at-a-time); this ruling is the approval-on-record it needed. Changing the LIVE legacy Nemotron path to verification_failed-with-NULL on score-50 is a behavior change on the byte-identical legacy path. Zero code written. Needs explicit owner confirmation before anything lands.
5. F5 — incident-media keys. RULING 2026-09-24: no keys needed — download stock imagery directly. EXECUTED via Wikimedia Commons (awaiting owner ratification of the host swap, flagged below). scripts/synthetic_media.py (keyless Commons API, permissive-license allow-list, https+Wikimedia host allow-list, attribution sidecar per frame + per-scenario manifest) — corpus at out/media/stock/: 75 frames, 60 CC / 15 PD, all titles unique, 12/13 scenarios at target 6. Commons genuinely lacks "delivery driver at porch" photography: delivery_driver plateaus at 3 — recorded, not padded. Hardening found en route (all TDD, f19f3e7f + this commit): transient 429 bursts → bounded retry + loud per-file skips + 0.5 s pacing; resume TOPS UP instead of spinning; duplicate titles deduped (the same photo filled 2–4 slots of one scenario pre-fix); document-mime scans (.djvu is a Commons "bitmap") and non-JPEG bytes refused. Google Images was NOT used: scraping violates its ToS and an unidentified image's license is unknowable — an unlicensable frame can never ship; Commons carries machine-readable CC/PD per file. Owner ruling on media (2026-09-24, after the S-3 re-run showed keyword stock cannot build doorbell-plausible INCIDENT scenes): infrastructure stack first; media content gets replaced tonight (several hours out) — Commons frames carry the benign half meanwhile. Not blocking: G0 infrastructure work proceeds; when the owner's replacement media lands, load_stock_items re-freezes and S-3's incident half re-runs unchanged. AMENDED 2026-09-25 — owner ruling supersedes 'tonight': incident video will be SYNTHETICALLY GENERATED by the owner, unscheduled; 'don't be concerned… we just need a functional pipeline.' Task 0 stays a G0 tail that arrives when it arrives; nothing in P0 waits on it. Incident labels arrive with generation (born-labeled), which retires the S-3 corpus-construction blocker by construction.
6. F6 — eval-store location (D10). RULING 2026-09-24: APPROVED — out/eval-store/ (GPU root's mount root is virtiofs-squashed read-only at top level; out/ is the writable share beside models/). Executed: D10 guard refined TDD-first (repo-residence by resolved path, bdeff1a8 — the "409f…" cited here earlier was a dead hash, corrected at G0 close), 408 label-set items frozen off-repo out/eval-store/eval.sqlite, roundtrip proven [V]; +13 media-bearing stock items added by load_stock_items (04e83371) → 421 items now in the store (408 label-only + 13 stock), re-counted at close [V]. Wipe at teardown per D10. The store path is a required argument and the code refuses repo/capture-root media at write time, but the permanent off-repo location is the owner's call (suggested: $AGENT_GPU_DIR/eval-store, wiped at Brev teardown). Blocks: freezing any real items.
7. F7 — push approved but origin is host-local (2026-09-24). Owner ruled "Push to origin now"; git remote -v shows origin → /home/msvoboda/github/nemotron-v3-home-security-intelligence (a host path, unreachable from the sandbox; no network/GitHub remote is configured, and none will be invented). ~~Workspace is direct mode — the sandbox IS the host checkout — so every commit on feat/vss-gaming-gpu-profile is already in the host repo; the push was moot at the moment it was ordered.~~ [CORRECTED 2026-09-25, owner ruling: that sentence is wrong — /agents/agent-vss1/workspace is a SEPARATE clone with its own .git, NOT the host checkout, so commits here were never in the owner's ~/github checkout and the push was NOT moot. The host-path origin tracking ref is stale and misleading: any "ahead N, behind M" it prints is against a host snapshot this clone does not share. Test mode with if [ -d /run/sandbox/source ] before reasoning about how commits reach anyone.] When a network remote exists, git push -u <remote> feat/vss-gaming-gpu-profile completes the intent. UPDATE 2026-09-25 (owner directive "commit and push"): the canonical remote was found in README (github.com/mikesvoboda/nemotron-v3-home-security-intelligence) and added as remote github; git ls-remote reads it fine (credential injection works for reads) and gh/main is an ancestor — branch is 36 commits ahead of GitHub main, zero divergence, fast-forward clean. The PUSH 403s: injected credential is account nv-msvoboda, which lacks write on mikesvoboda/…. Fix is owner-side: sbx secret set github --sandbox agent-vss1 -t "$(gh auth token)" with a token holding write on the repo; then git push github feat/vss-gaming-gpu-profile. The literal origin (host path) remains unreachable from the sandbox and remains not the way out. CLOSED 2026-09-25, executed: owner set the sandbox github secret to a mikesvoboda token (gh auth switch first — the first store had re-minted the machine account's own token, which is why the identical 403 survived it; the credential-injection chain is per-sandbox-secret, verified by probing api.github.com/user from inside). git push github feat/vss-gaming-gpu-profile → * [new branch], remote tip 674415b1 == local HEAD [V]. 37 commits (36 ahead of main at fetch time + the F7-update commit itself) now on GitHub. origin stays the host path; github is the network remote from here.
8. Deferred seam, surfaced early — ProviderId for the VLM. CLOSED 2026-09-25 by task 1.1: MINTED NEW ProviderIds (OPENAI_VLM/RTVI_VLM), not a reuse of LLAMACPP_LLM — spec §3 Slots names them, and provenance must record the actual engine (an OpenAI-compatible vLLM and llama.cpp serve share the union per_model_server column as subsets, each required={"vlm_assess"}; reusing LLAMACPP_LLM would erase which engine answered). Full evidence in the Phase 1 table, row 1.1.
9. F8 — stray image tag ai-vlm:sm11090 (found by the G0 close-out audit, 2026-09-24). agent-gpu images shows the b11090 image carrying BOTH ai-vlm:sm103-b11090 and a mistyped ai-vlm:sm11090 (sm_103 + b11090 mashed into one) on the same id — so the store lists 3 rows but 2 distinct images (size-summing scripts double-count). Phase 1's compose wiring could pull the wrong name. Left for owner: agent-gpu rmi on a shared-id tag could delete the image itself, and broker rmi semantics here are unverified — refusing to guess at someone's GPU store. CLOSED 2026-09-25 by owner ruling + executed evidence. Owner (who owns the runner) directed Option A: agent-gpu rmi ai-vlm:sm11090 from the sandbox — the runner translates to podman rmi --force localhost/agent-vss1/ai-vlm:sm11090 and logs an rmi event; ID-shaped refs are mapped to nonexistent session names, so the sandbox cannot delete an image by ID. Executed: runner returned {"image": "localhost/agent-vss1/ai-vlm:sm11090", "removed": true} [V]; agent-gpu images now shows 2 images / 2 names — a0fcc4267d5a keeps ai-vlm:sm103-b11090 at full 3,629,843,550 B, 44979c2eb92a untouched. Shared-tag rmi --force untags, does not delete — learned rather than guessed, and Phase 1's compose wiring now has exactly one name per image. The pre-closure hedge (broker rmi semantics unverified) was correct caution but over-conservative: the CLI's own help documented rmi <tag>; the owner's runner knowledge retired the uncertainty.
10. F9 — no functional production system (owner ruling 2026-09-25). "We do not have a functional system at the moment. We are building one now. The previous system has been offline." Consequences, all recorded where they bite, none silently absorbed: (a) the control timestamp / control-freeze EXECUTION premise is void — there is no live pre-switch traffic to freeze; P0 Task 1's code still ships (cheap, tested, useful if history returns) but closes code-DONE/execution-ruled-N/A, and sequencing rule 1 (0.1-before-0.2) is dormant until the home stack serves live events again; (b) Task 6's ordering guard ("wait for the control timestamp") is lifted by the same ruling; (c) the §5 owner labeling pass cannot run through the feedback UI with nothing running — label provenance shifts to born-labeled synthetic generation (ruling 2); (d) M0's three pieces survive without traffic, with evidence sources restated: A5500 healthy = owner bring-up [O], eval store frozen = born-labeled synthetic + stock items (already 421), S5-on-legacy = serve + runtime probe (probe generates its own requests; no production traffic needed). The spec's Phase-0 text is NOT edited — this row is the environment-of-record that the dated P0-plan amendment points at.
11. Standing stop-and-ask list (kickoff goal): VLM pick at M2, cutover sign-off 3.1, any D#/S# change, dgx-inference, Brev spend, agent-gpu refusals/VRAM squeeze, R10, doc-12 items, ~~pushes~~/PRs/merges. AMENDED 2026-09-25 (owner ruling): "Standing permission: after each committed Phase 1 task, push feat/vss-gaming-gpu-profile to the github remote without asking. PRs and merges still need my go-ahead." So: a committed Phase 1 task carries its own push; opening a PR and merging remain owner-gated. The kickoff goal file's stop-and-ask line still names pushes — this row is the dated supersession (same convention as the F10 spec-rev-5 amendment), and reports/asks here follow it.

12. F10 — the legacy path is unsupported; S2/S3 become fixed bars (owner ruling 2026-09-25) [O]. The owner asked to remove legacy-path support from the plans. Asked three follow-ups, the owner chose: (1) fixed bars, no legacy yardstick. S2/S3 are measured against fixed numbers, S2_MAX and S3_MIN, which the owner sets before step 2.2. There is no control verdict and no offline 30B replay. (2) Keep the 0.3 code already in PR #6678, including the integration-tier legacy-wire pin (d1dd6cab). (3) Apply the edits now. They were executed as spec rev 5, plus amendments to the P0 plan, brief 13, doc 12 and the two index docs. The commit that adds this row was written from the owner's host session, not by this sandbox. Consequences:

    • 0.1's execution and step 0.2 are removed.
    • M0 = Phase 0's code merged, with every CI tier green, and the eval store at the size bar.
    • The A5500 comes up in vlm mode as new step 1.7. The a5500_precheck.py checks llm_model and ai_llm_mount become obsolete there.
    • Phase 3 "Cutover" becomes "Go-live". Its fallback is the §6 detector-only rule, or the last model/prompt that passed the gate, not a legacy rollback.
    • P0 Task 3's home-endpoint probe half is removed.
    • R8 now also deletes the legacy LLM path.
    • The legacy code stays in the repo, unsupported, with its tests passing, until R8.

    This supersedes F9 (a)'s "re-arms" clause and item 11's "cutover sign-off" wording. Item 11 now reads as go-live sign-off, plus the S2/S3 bars as a new stop-and-ask. Reported alongside, for the S2/S3 bar-setting: the S-3 re-tally shows the smoke-test model answered uncertain on 73 of 75 frames. A hedging model passes a fixed S2 and fails S3, so report the verdict mix beside the bars (spec §5 metric definitions).

13. PR #6678 saga — opened, main integrated, three CI failures fixed (2026-09-25). Branch pushed to the github remote and PR #6678 opened against main (owner chose "Integrate + open PR"). github/main merged clean except .secrets.baseline (conflict markers make it unparseable — resolved to valid first, then the repo's own hook regenerated over the merged tree; registry semantic diff: 419 entries both sides, 0 lost/0 added). CI then failed three jobs, each diagnosed from completed-job logs, each fixed with attribution-first evidence: (a) Dead Code — vulture only flags in the CI-exact full-tree invocation (uv run vulture backend/ vulture_whitelist.py --config pyproject.toml; single-file runs over-report): 9× *a2/**k2 unused-arg captures renamed, exit 0 [V]; (b) Collection Sanity — the named check PASSED; real failure was a later step, suppression-registry-gen.py --check drift → registry regenerated (663861f5), plus a hook-convergence commit after prettier/detect-secrets churn (08ef99f0 — lesson: hooks modify files DURING a gate run; --no-verify then captures the pre-hook state; re-stage and re-gate until zero churn); (c) WS contract test — "Schema has undocumented fields: {'verification'}": P0.4 added the field, the test's hardcoded drift set was stale → fixed the SET (test side), not the schema (105fdac1). CI on 105fdac1: API shards 4/4 + WS + Models green; the shard failures were the Services-tier nemotron population. Full-tier attribution of the 32 local failures: 22 = the P0.3 ship-default hitting legacy fallback assertions (causal proof: 73 green with flag off) + 3 = mock-spec blast radius + 7 = ledger load-flake families (14 green serially) + the 263-error cache/:6379 burst family recorded verbatim at 5300b455 (branch touches none of the errored files). The first response — a tier-wide legacy env-pin (d1dd6cab) — was SUPERSEDED by the owner same day; see item 14.

14. Wire doctrine, owner ruling on PR #6678 (2026-09-25): the integration tier runs the SHIPPED default; legacy pinned only per-subject [V]. The owner overruled d1dd6cab's tier-wide legacy_wire_pin: "Don't pin the legacy wire tier-wide. Make the integration mock LLM pass the enforcement check so the tier exercises the shipped default; pin legacy only in tests that are about legacy." This supersedes F10 item (2)'s endorsement of that pin. Executed in 53a64cfd: conftest's mock_llm_enforces_grammar (autouse) patches the analyzer's single probe transport (_probe_completion — the same helper scripts/vlm_probes/enforcement.py drives), so the gate logic — status handling, JSON parse, nonce-const compare, per-endpoint caching — runs UNMODIFIED under flag=True; the stand-in verifies the nonce-const contract rides the schema it was handed and answers PROSE (the analyzer's own IGNORED evidence, which raises) to a malformed probe, so probe-shape drift can never fake a pass. The new per-test legacy_wire fixture goes ONLY on the five LLM-failure-fallback tests that assert pre-0.3 50/medium semantics (test_nemotron_analyzer ×2, test_llm_analysis_pipeline ×2, test_pipeline_e2e ×1) — requested first so the analyzer fixture builds under the pin. Success-path tests (their mock carries its own score) now genuinely exercise constrained decoding ON. Shadow-mode mock settings: nemotron_constrained_decoding_enabled False→True — the file's subject is shadow prompts, not legacy. Evidence: five files 54 passed; full integration tier 6 failed / 3807 passed / 263 errors — identical to the banked baseline, zero new identities (all six are the ledger flake families) [V]; unit 28,402 passed (the known systemctl env-fail); contracts 612; ratchet-check/census/registry-gen --check and full-tree vulture all exit 0. Related CI fix in the same commit: the ratchet-check STALE on test_eval_store.py:295 (Collection Sanity's real failure on head d1dd6cab) — the eval_store GPU-stock guard moved the imperative skip 295→300; registry re-keyed by the generator (semantic diff: exactly that one re-key), secrets baseline refreshed. Consequences for future sessions: never re-widen a wire pin; the /goal prompt's legacy invariant now carries this ruling (the old "byte-identical except approved 0.25/0.3" wording invited exactly this mistake).

15. agent-gpu CLI unreadable mid-session (2026-09-25, found during 1.3's live-wake evidence pass) [A — owner ask queued]. agent-gpu status → command not found. Diagnosis from inside the sandbox: /usr/local/bin/agent-gpu is a symlink to /home/msvoboda/.local/bin/agent-gpu, and stat on the symlink target reports -????????? (mode/owner unreadable — EPERM), i.e. the target became invisible/inexecutable to this sandbox between 1.2's serve proofs (same image, same broker, earlier today) and now. The broker endpoint itself is reachable and its token readable, but hand-rolling the broker HTTP API would be going AROUND agent-gpu — forbidden by the invariant — so the honest state is BLOCKED, not worked around. Consequence: 1.3's live sandbox half (idle-sleep the served ai-vlm, open a batch-shaped wake, observe exactly one request) cannot execute; recorded as BLOCKED [A] on row 1.3 rather than an unobserved pass. The request-side contract is pinned in unit tests (wake fires exactly-once per batch open, fires after the camera lock releases, never on reuse/fast paths; wake() records record_model_cold_start("ai-vlm") only on the 200 arm). Owner ask: restore sandbox readability/execution of the agent-gpu CLI target (or name the sanctioned alternate), then the live wake/assess [V] halves run against an --vram 14 serve as planned. Until then every GPU-touching step inherits this blocker.

    CLOSED 2026-09-26 — broker restored (owner host-side fix) and the deferred live evidence EXECUTED [V]. agent-gpu status → ok, fence true, free 49064 MiB. Serve (same 1.2 recipe, ai-vlm:sm103-v12 --vram 14, short idle SLEEP_IDLE_SECONDS=45): first attempt died with GGUF Permission denied — the mount root models/ had come back mode 750 agent:agent (F1's class again, this time the dir was agent-owned, so the chmod was self-service: chmod 755 models/); second attempt loaded, /health ok at http://host.docker.internal:18100. Sleep observed server-side: que start_loop: entering sleeping state / srv handle_sleep: server is entering sleeping state — while /health kept answering {"status":"ok"} THROUGH the sleep (the §6 lesson proven live: a health probe reaches the socket and wakes nothing — breaker-push health stands). Wake proof: after a second sleep event, the REAL wake_ai_vlm() (production function, dev-env settings, AI_VLM_URL pointed at the published port) → True; engine log went exactly +1 POST /v1/chat/completions … 200 and +1 handle_sleep: server is exiting — one request, one wake, from sleep. Assess proof: VlmClient.assess against the live engine returned a strict-schema VlmVerdict (verdict=rejected, score=0, full key set) for a synthetic stock frame. Guard proof, live: the traversal/privacy guard REFUSED an absolute path outside the capture root (VlmImageError … refused before any read) — evidence from the negative side, then the assess ran with the frame under /export/foscam. Two harness lessons banked (both were MY driver env, not the code path — the swallow-all belt correctly hid each): Settings defaults environment="production", which activates the strict password validators (use ENVIRONMENT=development for sandbox drivers), and python /tmp/x.py puts /tmp on sys.path (needs PYTHONPATH=workspace). Cleanup: agent-gpu rm vlm-live-13 → containers: []; temp capture-root copy removed. Row 1.3's BLOCKED [A] marker is superseded by this row.

16. F11 — specialists resident, and their outputs reach the VLM (owner ruling 2026-09-25) [O]. Written from the owner's host session as spec rev 6 plus Phase 1 plan amendments, in the commit that adds this row. The owner asked whether Triton is still needed, whether it complicates a future VSS integration, and whether on-demand loading gives the VLM better context. Findings (host-side reads of this tree):

    • Triton stays. It hosts the YOLO26 gate and re-ID. VSS is itself Triton-based: RT-VLM's image carries Triton 26.03, RT-CV can use nvinferserver, and RT-Embed runs on tritonserver (audit 09 §1-§2). So Triton doesn't complicate Phase 4. Co-residency with RT-VLM's fixed vLLM reservation does, and a static Triton footprint is the easy neighbour for it.
    • With one load set left after rev 5, explicit mode has no job. A static vlm model repository with --model-control-mode=none gives the same residency, avoids specialist cold starts under S4, and leaves the 501 public surface alone.
    • Loading policy doesn't create context. Context comes from what reaches the prompt, and nothing did: vlm_analyzer defaults specialist_outputs to empty, and AssessInput had no such field, so live and replay would also have diverged.

    Rulings:

    1. 1.4 is rescoped to the static repository (YOLO26 + re-ID + optional threat). Explicit mode, real load/unload, the contract flip and the specialist wake hook are dropped. Revert 7f7113ed and discard the uncommitted lifecycle.py unless something depends on them.
    2. New 1.3b: face match, plate read, re-ID and the optional threat detector feed specialist_outputs. A failure records unavailable and never blocks the verdict.
    3. The AssessInput freeze is reopened for exactly one optional specialist_outputs field, default empty, so the 421 stored items stay valid. Replay never re-runs specialists.
    4. Synthetic items gain verdict-changing specialist cases.
    5. D3 now allows the threat detector as an optional fourth specialist.

    Ruling 1 executed (sandbox session, 2026-09-26) [V]: the explicit-mode artifacts were discovered mid-flight (the agent had built the gateway load/unload plumbing before the host-session amendment landed in the work tree), so the "unless something depends on them" check is concrete. Nothing depended on them: no module imported adapters/lifecycle.py (written minutes before, uncommitted, unmounted), and 7f7113ed had exactly two consumers — its own test additions and the adapter being discarded with it. Disposition: git rm of the two uncommitted files (no history to rewrite), and git revert 7f7113ed → dd157997 (kept as history rather than a force-push, since it was already pushed to github). Post-revert proof: git diff 27f4bd96 over non-docs paths is EMPTY (code identical to the last fully-green head) and the two gates re-pass — uv run pytest ai/gateway -q 248 passed / 1 skipped, scripts/gen-ai-contract.py --check "AI contract is current". The contract's model_preload/model_unload availability and model_management.py's 501s were never touched. What was LEARNED while the explicit-mode design was live stays useful for the static-repository task: no gateway lifecycle endpoint exists today (the Tier-A absence guards at test_client_conformance.py:1139-1190 still hold — they stayed green untouched); the 14 Triton repo names, the --model-control-mode=none flag site (entrypoint.sh:131), and the models.yml preload: flag being dormant-everywhere are all re-verified facts for choosing the repository-filter mechanism.

17. F12 — specialist model picks, and licenses are not a criterion (owner rulings 2026-09-25) [O]. Written from the owner's host session, together with the Phase 1 plan's F12 amendment (Task 3b) and docs/vss-integration/14-specialist-model-research.md, in the commit that adds this row. Context: the 3b stop-and-ask reported that the face leg has a gallery and matcher but no server-side embedding extractor, and asked for a go or no-go on option A (a model_zoo ArcFace loader). The owner also commissioned research on memory-light specialists that add intelligence the VLM lacks. Three host-side agents verified candidates on primary sources (model cards, repos, NGC pages); Perplexity deep research supplied leads only. Doc 14 has the tables, the sources and what is unverified.

    Rulings and dispositions:

    1. Face gap: GO on option A, with conditions. A loader interface (aligned 112×112 crop in, L2-normalized 512-d out, CPU onnxruntime, absent weights mean unavailable). One embedding space: enrollment computes gallery vectors server-side, the model id is stored on each embedding, and a model mismatch yields unavailable (re-enroll). Four outcomes: household match, unknown, not identifiable (below a size-and-score gate) and unavailable. unknown is never emitted for a crop that fails the gate. Models: SCRFD-10G-KPS plus w600k_r50 from InsightFace buffalo_l, only those two ONNX files, hash-pinned. B (detection only) and C (reviving the old enrichment service) are rejected.
    2. Licenses are not a selection criterion. Owner, verbatim: "we can use yoloe-26, its fine. dont worry about license problems." AGPL (Ultralytics, including the YOLO26 gate), GPL, CC BY-NC and research-only weights and datasets are acceptable. A license is still flagged only when it restricts the use itself: KPR's Hippocratic License 3.0 (surveillance clauses), and BlazeFace's card, which excludes surveillance and identity use. This ruling supersedes the host session's earlier AuraFace-v1 + YuNet face pick. That pick was made under license filtering and was never built.
    3. YOLOE-26 is approved for a future open-vocabulary specialist slot. That is a spec change (rev 7), not Phase 1. It is also where weapon evidence returns, as hints gated on overlap with a hand or arm.
    4. Threat call input for 3b (the call is still 3b's to ledger). The research recommends not including Subh775/Threat-Detection-YOLOv8n. Its card shows identical 83.0% recall on every class, an unnamed Roboflow dataset, and a "research and educational purposes" disclaimer. The best published CCTV result is handgun AP50 57.4, dropping to 3.7 across datasets.
    5. Re-ID must prove one vector space end to end before it is called ready. The inventory cites CLIP-768 at reid_service.py:430; the schemas document 512-d OSNet. A general CLIP/SigLIP embedder is a quality gap: zero-shot SigLIP2 re-ID measured mAP 2.8-14.2% in a 2026 11-model comparison. The swap to a trained re-ID model (PersonViT ViT-S/16 or CLIP-ReID) is a rev 7 item.
    6. Embedding storage: PostgreSQL, no vector database. The owner asked whether to run Qdrant or use PostgreSQL; the host answer was adopted with the owner's instruction to "edit the plans with this information". At home scale (a gallery of about 200 vectors, re-ID in the tens of thousands, novelty in the hundreds of thousands at most) Qdrant adds a service and a second copy of the truth, outside FK cascades and retention sweeps. Add pgvector only when a consumer needs indexed search over more than ~100k vectors. When it comes, build the extension into the current postgres:16-alpine image, or dump and restore. Do not swap to the Debian pgvector/pgvector image over the existing data directory: musl and glibc collations differ, so text indexes go silently inconsistent. The same slice should consolidate today's five embedding formats (LargeBinary ×3, JSONB ×2) into typed columns with a model id.

    Facts corrected by the research [V on primary sources]: the incumbent OSNet-AIN's "MSMT17 Rank-1 73.3%" is the multi-source MS+D+C→Market Rank-1; single-source MSMT17→Market is 70.1. That checkpoint's training includes the withdrawn DukeMTMC. The fast-alpr stack pins the v1 OCR (cct-xs-v1), and both models total about 10 MB, not 28 MB. The old face service's "~1.5 GB VRAM" is the insightface loader putting all five buffalo_l models on the GPU, not the two models the face leg needs.

18. F13 — Phase 2 may run before M1 closes (owner ruling 2026-09-25) [O]. Written from the owner's host session, together with the Phase 1 plan's sequencing rule 8, in the commit that adds this row. The owner asked whether the agent can stay busy for the next several hours. Phase 1 has roughly 5-9 hours of agent-doable work left, then it reaches owner gates: the 1.7 A5500 bring-up [O] and the PR that "every CI tier green" needs for M1. The owner approved the host session's proposal to run Phase 2 in parallel rather than idle. Terms:

    1. Order. Finish Phase 1's agent-doable work first: the rest of 1.3b, 1.5, 1.6, 1.7's repo side (precheck + dated handout), and the M1 code review and report draft. Phase 2 fills the time spent waiting on owner gates. It is also allowed mid-Phase-1 while a Phase 1 question waits on the owner: switch rather than idle.
    2. The Phase 2 plan is written with the writing-plans skill, as the brief requires ("one phase at a time"; Phase 1's plan is written, so Phase 2's is next).
    3. 2.1, the replay harness (backend/evaluation/vlm_replay.py, spec §5:261). It replays each item's stored specialist_outputs and never reruns the specialists (rev 6).
    4. 2.2, the bake-off runs, on the GB300 through agent-gpu. This is legitimate for S2/S3 because salience depends on the model build (weights, quantization, engine), not on the GPU (spec §5:284-286). Run each candidate in the build it would ship in. Candidates (spec §5:280): Qwen3-VL-4B, Qwen3-VL-8B, Nemotron-12B-VL (after the llama.cpp bump, as a new ai-vlm image through agent-gpu), and Cosmos-Reason2-8B (vLLM BF16, quality reference only). Serve one candidate at a time, with an honest --vram and agent-gpu rm when done, and never touch dgx-inference.
    5. Not measured on the GB300: S1 (fit) and S4 (latency). Those come only from 24 GB-class hardware: the A5500 at 1.7, or Brev at 2.3.
    6. Still owner-gated: S2_MAX and S3_MIN. The runs and raw metrics may proceed, but the 2.2 report's pass/fail verdicts wait for the owner's numbers. Also still owner-gated: 2.3 Brev spend, the M2 VLM pick, PRs and merges, and every other item on the standing stop-and-ask list (item 11).
    7. Pin every bake-off run to a commit hash. Phase 1 is still changing the prompt path; for example, 1.3b's prompt-hygiene work changes what specialist_outputs puts in front of the VLM. If a later Phase 1 commit changes the prompt, the vlm_assess payload or the specialist texts, rerun the affected candidates and say which runs were superseded.
    8. Phase gates are unchanged. M1 still closes Phase 1, and Phase 3 (go-live) still needs both M1 and M2.

19. F14 — the S2 and S3 bars are set: S2_MAX = 5%, S3_MIN = 90% (owner ruling 2026-09-25) [O]. Owner, verbatim: "use 5% and 90%, record them in the ledger." This answers the spec's S2_MAX/S3_MIN [?] markers (§1 S2/S3 rows) and the brief's stop-and-ask item "the S2 and S3 bars". Both were set before any bake-off result exists: the eval store's runs and results tables are empty. Written from the owner's host session, in the commit that adds this row.

    Rulings:

    1. S2: at most 5% of labeled-benign items at risk_level ≥ medium (score ≥ 30 under the default SEVERITY_LOW_MAX = 29).
    2. S3: at least 90% of labeled incidents at or above their expected minimum level.
    3. Both bars are judged at one operating point. Report each candidate's S2 and S3 from the same prompt, thresholds and build. Tuning one bar with one setting and the other with another doesn't count.
    4. Reporting rule: give each bar's n, the point estimate, and a 95% Wilson interval. Pass means the point estimate meets the bar. Label it marginal when the interval straddles the bar. The spec's verdict mix (the uncertain rate) stays beside the bars.
    5. Not adopted: the host session's optional "every critical incident ≥ medium" sub-bar. It would be an S# change (a spec revision), and the owner didn't take it up.

    Why these numbers (the host session's reasoning, which the owner accepted):

    • S2 = 5% is about the tightest bar the eval set can resolve. There are 139 benign items, so one item is 0.72 percentage points. An observed 2% has a 95% interval of 0.7-5.9%, which can't be told apart from 5%. A stricter bar needs more benign items.
    • In daily terms, 5% means about 1 false medium-or-higher event per day at 20 benign events/day, and 2.5 per day at 50. Actual notifications are fewer: a rejected verdict never notifies, and per-camera thresholds and quiet periods filter further.
    • S3 = 90% is resolvable: on 274 incidents, the interval around 90% is 85.9-93.0%. It is deliberately demanding. "At or above expected" counts one band short as a miss, and G0's S-3 test saw Qwen3-VL-4B hedge uncertain with low scores. If no candidate reaches 90%, the lever is prompts and specialist context, not the bar.

    Eval-store facts found while setting the bars (read-only query of $AGENT_GPU_DIR/out/eval-store/eval.sqlite, 2026-09-25) [V]:

    • Composition: 421 items, 139 benign (134 synthetic + 5 stock) and 282 incidents (274 synthetic + 8 stock). Every benign item expects low. Incident expected minimum levels: 30 critical, 118 high, 126 medium, and 8 low.
    • Only 13 of 421 items have media (the stock items). The 408 synthetic items are born-labeled but still have no images; they wait on the owner's synthetic media generation (F9 ruling 2). Consequence for F13 term 4: until that media exists, 2.2's bake-off runs cannot measure S2 or S3. 5 benign and 8 incident items resolve nothing. 2.1 (the replay harness) can still be built and proven on the 13 stock items plus fakes. Owner action: generate the synthetic media for the 408 items.
    • 8 incidents expect low, so any score satisfies them and they inflate S3 for free. That is a label contradiction for an incident. Owner decision pending: relabel them or exclude them from S3. Until it's made, the 2.2 report gives S3 both with the 8 (n = 282) and without them (n = 274). DEFERRED 2026-09-26 (owner, verbatim): "ignore this for now" — the double-report (S3 with n = 282 and without n = 274) stays the reporting rule until the owner returns to it.
    • CLOSE POINTER 2026-09-27 (item 33): this row stays [O] until the corpus lands — but the door is now pinned: a born-labeled batch that is media-bearing, attribution-carrying AND specialist-declaring at once freezes through the shipped importer with its labels refused rather than guessed (bae92f47, item 33, dry-run at 100/24 through freeze+replay). What remains open is the corpus itself, not what our boundary does with it.

20. Re-ID one-space swap: SIZE REPORT + decision ask (2026-09-26, owner instruction "if switching the store is bigger than the stage slice, stop and tell me the size first") [A]. Measured against the tree at 752ad1e0: ~16 non-test files, two shippable slices — larger than one stage slice, so this is the stop. (a) Schema + provenance: model_id column on PersonEmbedding and EntityEmbedding (same three-twin discipline as the face pair: model, migration SQL, integration conftest) + the sentinel machinery extended to person vectors + household_matcher.cosine_similarity dim guard + both comparison readers (household_matcher.py:298 store side; the probe side) gated mismatch ⇒ "unavailable (re-enroll)" + the specialist leg's no-score line becomes the real leg (gate from config). (b) Producer swap: reid_service's embedding leg to OSNet-AIN x1.0 at the TWO production call sites (household.py:551 enrollment, enrichment_pipeline.py:5795 trail capture) + EntityEmbedding writer(s) + the /clip-router retirement's residual docs. Existing assets make this cheaper than it looks [V]: backend/services/osnet_loader.py already loads the SAME OSNet-AIN x1.0 in the backend (torch+torchvision CPU present: 2.14.0/0.29.0), ai/gateway/export/export_reid.py exports the same .pth to Triton reid, and download_models.sh already fetches the single-source MSMT17 checkpoint — so the store's new producer and the resident model are one model id, osnet@osnet_ain_x1_0_msmt17@…. Costs/risks to price in: the .pth has NO sha256 pin today (face-pair doctrine F12 requires one — the file is NOT in this sandbox's GPU models root, so the pin lands at download time; hash recipe above); backfill is IMPOSSIBLE — every existing 768-d CLIP vector (member + entity stores) becomes legacy-flagged ⇒ "unavailable (re-enroll)" until re-enrolled, i.e. the feature reads unavailable on any installed system until members are re-captured (greenfield here, so cheap NOW, not later); 512-d replaces a general CLIP embedder whose zero-shot re-ID quality is measured at mAP 2.8–14.2% (ledger item 17) — trained OSNet single-source MSMT17→Market R1 70.1 is the honest number, still below PersonViT 89.2 / CLIP-ReID 88.7 (rev-7 swap candidates stand). Two options, owner's pick: (1) ship slice (a)+(b) now — one space end to end, F11-compliant, OSNet-grade quality; or (2) ship slice (a) now + leg stays no-score until the rev-7 model pick — provenance honest either way. Nothing built ahead of the ruling; slices staged in F13's order (1.5/1.6/1.7/M1 first) either way. RESOLVED 2026-09-26 (owner, verbatim): "full swap. ignore previous architecture. we do not have to support backwards compatability." That is option (1) and more: the back-compat premise this report priced ("every existing 768-d vector becomes legacy-flagged ⇒ unavailable until re-enrolled") is retired — no legacy-flag columns, no migration shim preserving old vectors, drop-and-re-enroll is legitimate. Slice (a)+(b) ships as one authorized effort, F11 (one space, model id on every stored vector, mismatch ⇒ "unavailable (re-enroll)", never a score) and F12 (two SHA-256-pinned CPU-ONNX files, never insightface.FaceAnalysis, the producing model named before "ready") still bind. The "marginal / rev-7 swap candidate" note stands as history: OSNet ships now, a PersonViT-class upgrade remains a later, separately-ruled swap. CLOSED 2026-09-27: the ruling shipped end to end — see item 22 for the weights pin, the belt grammar shared by all three producers, both API/config changes (D-1 410, D-2 0.7 PROVISIONAL), the real-bytes [V] driver at 8/8, and the tier identities on the shipped tree. This item's cost estimate stands as the record of what was priced before the ask; the "two slices" framing collapsed into one authorized effort exactly as resolved here.

21. PR for Phase 1 1.1–1.5 opened (2026-09-26, owner instruction "push all of our changes to origin and open a PR") [V]. Executed literally, with one environment fact: origin is unreachable from this sandbox. git remote -v shows origin = /home/msvoboda/github/nemotron-v3-home-security-intelligence, a host path that is not mounted here (ls → No such file or directory; git ls-remote origin → "does not appear to be a git repository"; no /run/sandbox/source, so this is clone mode with the host tree absent). So the push went to the reachable remote, github — git push github feat/vss-gaming-gpu-profile → 4c0f12a1..f9cd229b, and the whole Phase 1 span is on GitHub. The owner's own host checkout still needs git fetch github to receive it; nothing was force-pushed anywhere. [O] The PR already existed, so no duplicate was opened: gh pr list --head feat/vss-gaming-gpu-profile returned #6681 OPEN, authored by mikesvoboda at 2026-09-26T00:23Z against main — the owner's host session had already opened it from this branch, still empty on the raw template. A second PR from the same head/base would have been a duplicate, so the instruction was executed by filling in #6681 instead: title → feat(vlm): Phase 1 - the VLM path runs end to end and ships as the default, body → the real 26-commit scope, the seven gate identity sets, the known gaps (notification/alert-engine live-ness, breaker-push health, no CI on this branch), and the deploy note that PIPELINE_MODE + GATEWAY_MODEL_SET flip together. Verified landed: body 8904 chars, tail is the attribution line, updated_at 2026-09-26T18:19:20Z → https://github.com/mikesvoboda/nemotron-v3-home-security-intelligence/pull/6681 Two tooling notes worth keeping: (i) gh pr edit cannot write a PR body in this environment — it dies on GraphQL: Projects (classic) is being deprecated… and silently changes nothing (the follow-up --json body read still showed the old 2941-char template). gh api -X PATCH repos/<owner>/<repo>/pulls/<n> --input <json> works. Use the REST form for PR body edits here. (ii) gh pr checks 6681 reports "no checks reported on the 'feat/vss-gaming-gpu-profile' branch" — CI has not started on this head, so M1's "every CI tier green" premise is NOT yet satisfied by hosted CI; the ledger identity sets above are the sandbox-executed evidence. Owner action: confirm whether CI is expected to run on this branch (a workflow trigger may be scoped to main or to PRs from a fork), and merge #6681 when satisfied — merging stays owner-gated. CORRECTION + CLOSE 2026-09-26 (note (ii) is superseded; the three reds are OURS and are fixed). CI DOES run on this branch — it had simply not started when the note was written. Reading the completed-job logs, the three red gates on the earlier head (Mypy, Dead Code, Collection Sanity) traced to this branch's own 1.3/1.3b commits, and each got an attribution-first fix in f75a7fab (pushed): (Mypy) the 1.3b loader's Pillow-11 enum call sites (Resampling.BILINEAR/Transform.AFFINE + list(...) around mgrid slices) → CI-exact uv run mypy backend/ --ignore-missing-imports → "Success: no issues found in 1635 source files"; (Dead Code) the 1.5/1.3 factory seam's without_leg parameter vulture-flags only in the CI-exact full-tree invocation → vulture_whitelist.py entry → CI-exact vulture exit 0; (Collection Sanity) the census step first, whose unspecced_patch count this branch had moved 151→142 — converted via autospec=True (the sanctioned decrease path, PR #6595 precedent, NOT a baseline edit) at the 9 sites the classifier listed, then the ratchet step, whose pytest_skip_imperative registry anchors this branch's own conftest growth had drifted (+58 lines above the ~2556 anchors — masked until the census step stopped failing first) → regenerated by suppression-registry-gen.py (sanctioned machine-mintable path; semantic audit: exactly 10 anchor shifts + 2 WP2.4b kind re-adjudications, no reason lost). gh pr checks 6681 on head ca6d734c (last read at write time): 48 pass / 0 fail / 12 pending / 8 skipping (skipping = path-filtered jobs: Trivy/E2E-matrix/flake-consumer). M1's "every CI tier green" premise is now observed live on the PR head, not just sandbox-predicted — but at a PARTIAL head (18 jobs still running, incl. Frontend Vitest 8 shards, E2E, Backend Unit, Services, the Coverage Gate); close it on the final Phase-1 head at M1 (Task 8).

22. Re-ID FULL SWAP shipped — OSNet-AIN x1.0 is the one person-vector space end to end (2026-09-26/27, item 20's ruling "full swap. ignore previous architecture. we do not have to support backwards compatability") [V]. Head e28def43 carried slices A/B-core/A6/D-1; this entry closes B5/B6/B7/C/D and the [V] driver. Weights identity (F12): models.yml osnet-ain-x1-0 pins sha256: 8a07e8da38946f7cee37f4561617bf8b6d2fe8f3a4027852893ea092e46d919f (17,293,009 B, the repo's own ai/download_models.sh fetch of huggingface.co/kaiyangzhou/osnet), verified pre-torch.load by osnet_loader.load_osnet_model — wrong bytes are the same answer as no bytes (driver check 1: a bogus pin raises RuntimeError … never loaded, never run). The row's description got the honest number too: the shipped checkpoint is single-source MSMT17→Market Rank-1 70.1, not the mislabeled multi-source 73.3 (research doc 14 §flag; item 20 already recorded it). Belt grammar (F11): osnet_model_id() DERIVES osnet-ain-x1-0@osnet_ain_x1_0_msmt17@8a07e8da3894 from the models.yml row — never a literal — so the backend handle, the enrichment unified.reid_embedding payload and _safe_extract_osnet_embeddings stamp ONE string (B5b: "one space" is mechanical, and all three load the same pinned weights through the same row). Sentinel LEGACY_MODEL_ID = "legacy-unknown-provenance" (no "@") is the untrusted state and is never scored; it is also the person_embeddings.model_id column DEFAULT, so every pre-swap row lands untrusted — drop-and-re-enroll expressed honestly, not a shim (driver check 8, psql-verified DEFAULT 'legacy-unknown-provenance'::character varying). Guards: compare_person_vectors (the pure decision both readers share) scores a row ONLY when its model_id equals the probe's — not the threshold, not the bytes — and answers UNAVAILABLE_REENROLL when nothing is comparable; reid_service.cosine_similarity and entity_repository._cosine_similarity keep their own raise/zero behaviors as bug-vs-data signals, and osnet_loader's pad-or-truncate-to-512 became a raise (D-5: a wrong checkpoint never becomes a plausible vector). Redis partitions by producer (entity_embeddings:{model_id}:{date}, D-3) with the per-entry belt outranking the key; a beltless/legacy search returns zero candidates, which is the honest "no partition to read", never a cross-space score. API/config changes: D-1 the client-vector person-match endpoint is 410 Gone (a vector computed off-box cannot be trusted to share the space and a client-claimed model_id is no trust anchor — the face client-vector enrollment precedent), with docs/openapi.json + frontend/src/types/generated/api.ts regenerated in the same slice and npm run typecheck clean; D-2 reid_similarity_threshold 0.85 → 0.7 PROVISIONAL (OSNet-space; the CLIP-era 0.85 would silently drop every legitimate OSNet match) and the value now rides ONE shared constant DEFAULT_SIMILARITY_THRESHOLD through routes, request-schema Field defaults and the OpenAPI-exposed default, so no surface can regress alone; calibration against real household galleries is the named follow-up, same note as the face thresholds. D-6 result.clip_embeddings → result.reid_embeddings (grep-verified zero frontend runtime reads). B5a — vehicles have no embedding producer in the shipped mode (a finding, not a silently-dropped case): _run_reid routed person and vehicle through the SAME call, but OSNet-AIN is a person model (256×128 person aspect, MSMT17-trained), so a vehicle crop through it is noise — and in vlm residency /clip is retired and the residency base set is (yolo26, reid). Vehicle identity therefore keeps riding plate match, which is already its primary path (match_vehicle tries plate first at similarity 1.0), and _match_vehicle_visual degrades exactly as it already did (RegisteredVehicle.reid_embedding has no production writer today). The endpoint + schema copy now say so (LEGACY branch, "no shipped producer"), and a vehicle-specific re-ID model (fashion-clip / CLIP-ReID class) is a named follow-up; the A3 model_id partition already admits a second legitimate space without risking a cross-space score. Also named, not taken here: retiring /api/reid/search (kept alive — model_id=None answering empty forever IS the F11 degrade, and retiring it is a new API decision), and removing the legacy CLIP-named payload keys (face_clip/vehicle_visual). The torchreid import hazard (B2) and how it died: import torchreid fails in this venv (its chain hits torch.utils.tensorboard → ModuleNotFoundError: tensorboard), and every existing test mocked sys.modules["torchreid"], so the tier could never see it — left alone, real OSNet loading would silently become RuntimeError in the field and the whole store would answer "unavailable" forever. Resolved by _ensure_tensorboard_importable(): a minimal, bounded, commented sys.modules pre-registration inside the loader's torchreid branch (SummaryWriter is trainer-only, never inference). Acceptance is the real-.pth proof, not a mocked import: driver check 2 loads the pinned checkpoint through the shipped loader in ~1.0–1.4 s and gets the exact belt + dim 512. [V] real-bytes driver — 8/8 PASS (/tmp/reid_realbytes_driver.py, aggregate metrics only, nothing committed; stock frames are public-domain Wikimedia, referenced by count only — D10). Weights staged under /tmp because the NEM-4501 path allowlist is /models,/cache,/tmp,/export/ai_models,/app/models,/test. ① bogus pin refuses pre-load. ② real load, model_id == osnet_model_id() == "osnet-ain-x1-0@osnet_ain_x1_0_msmt17@8a07e8da3894", dim 512, ~1.0–1.4 s CPU. ③ the producer surface (generate_embedding → (vector, model_id)) over 8 public stock frames from 8 scenarios: dim {512}, one belt. ④ geometry: self-cosine 1.000000, unit norms within 6.0e-08, 28 cross-image cosines min 0.343 / max 0.641 / mean 0.528 — real images separate, and nothing is a zero stub. ⑤ the shipped comparator on real vectors: same-belt same-frame → match (sim 1.000); sentinel-only gallery → unavailable_reenroll; threshold 0.99 → no_match. ⑥ the shipped VLM leg grammar on real vectors: 'matches household member Mike (100% match)' and 'unavailable (re-enroll)' — the leg's refusal is now a real computation, CROSS_SPACE_REASON deleted. ⑦ D-3 on live Redis :6380: exactly one partitioned key entity_embeddings:osnet-ain-x1-0@…:2026-09-27, belt-named search finds it, legacy-id search finds 0. ⑧ live PG :5433: an enrollment round-trips model_id='osnet-ain-x1-0@osnet_ain_x1_0_msmt17@8a07e8da3894', and the column DEFAULT names the sentinel. (Both ⑦/⑧ clean up their own rows; the leg's injected gallery lets the driver drive the SHIPPED leg, not a re-implementation.) The real defect the driver found (TDD red→green): reid_service did list(result.embedding) straight off the handle, and a numpy float32 array yields numpy scalars — which store_embedding's atomic Lua write (json.dumps, NEM-4474) cannot encode: TypeError: Object of type float32 is not JSON serializable. Reproduced at the exact site (element type float32) and seen live in the driver's Redis leg. Swap-introduced class: the retired CLIP producer arrived JSON-decoded from HTTP (already native floats), so the store path only met numpy when the producer became local inference — and the unit tier missed it because it asserted length, never element type (its ExtractDouble already builds a real numpy array, so the fix is meaningful, not circular). Red pin test_generate_embedding_returns_json_safe_native_floats (asserts type(v) is float and the actual json.dumps call), green at the producer's return: [float(x) for x in result.embedding]. The other two person-vector producers were verified, not assumed: both already convert via .tolist(). Contract canaries re-armed, not relaxed (item 14 doctrine — a canary that fires on drift re-arms at its new line): V3 source-line pins re-keyed :3955→:3961, :5214→:5220 (Slice B/C edits moved enrichment_pipeline.py), and N1b re-armed from the retired [0.1] * 768 fixture to the swap's own canonical B5 tuple at :385 — exactly the escape hatch its own docstring names ("rewrite against the NEW canonical literal"); the property is unchanged (0.1·√512 = 2.263 ≠ 1, so N1a's unit-norm provider still contradicts the fixture corpus). The fake-provider dim identities in the conformance tier did NOT move (that tier pins the gateway/Triton side, which already emitted OSNet-512 — the backend store was the outlier); no ai_contract surface moved, gen-ai-contract.py --check reports current, no golden regeneration. The sha256 literal needed # pragma: allowlist secret (detect-secrets). Sweep discipline: CLIP stays documented for the jobs it really has (scene classification, threat-description similarity, scene-baseline anomaly, SigLIP weather) — only CLIP-as-person-re-ID-producer retired, and the /clip router stays real; dated records (docs/plans, archive, vss-integration, superpowers, research) untouched. docs/benchmarks/model-zoo-benchmark.md got a dated erratum rather than a silent rewrite because BOTH of its embedding rows are stale against models.yml (clip-vit-l was removed by the xclip full removal #6649; osnet-x0-25 no longer exists) — flagged, its VRAM figures disowned, not laundered. docs/developer/entity-tracking.md's phantom env vars (REID_EMBEDDING_TTL_SECONDS, REID_MAX_EMBEDDINGS) were found pre-existing and left for their own pass, disclosed rather than quietly "fixed". Dormant code left alone (recorded so its silence is deliberate): backend/services/reid_matcher.py is NEM-3043 code with zero production importers — untouched by the swap, so a future reader does not mistake its CLIP-era shapes for live ones. scene_baseline/fashion_clip keep real CLIP dims (768) because those are their own models, not re-ID. Gate identities on the shipped tree (2026-09-27, after the float fix): unit -n auto → 30,358 passed, 1 failed, 123 skipped, 8 xfailed — sole failure test_deploy_phases::test_skips_when_skip_build, the known systemctl env-fail (its identity matches the 1.1/1.3b baselines; re-confirmed in isolation: FileNotFoundError: 'systemctl'); contracts -n0 --timeout=30 → 646 passed, zero xfail/skip in ai_providers; integration (live PG :5433 + Redis :6380, probed in-session first) → 4088 passed, 107 skipped, 2 xfailed, PYTEST_EXIT=0; gen-ai-contract.py --check → current; npm run typecheck clean. Diff scope: 63 files, +2337/−1111 (services, API routes/schemas, generated openapi.json + api.ts, models.yml, tests, docs). Collection Sanity fired on the swap head — the increase path, exercised as designed (2026-09-27, fix 61973aeb [V]). CI's Collection Sanity (zero-byte / zero-test tracked files) went red on 12f78722: e28def43's real-.pth proof added three imperative skips — its honest env gates (pinned weights absent / torch absent / torchreid's tensorboard chain unimportable; every CI env takes all three, every GPU box runs the real thing) — moving the pytest_skip_imperative census 96→99, plus anchor drift on four older entries from this branch's own file growth (the STALE/UNREGISTERED pairs). Repair per the WP1.3 doctrine the gate itself names: registry re-minted via the sanctioned suppression-registry-gen.py (semantic audit of the diff: exactly +3 entries, zero removals, rest pure anchor re-anchoring with identical payloads), baseline raised 96→99 in the SAME commit, and the census gate's own spec-mirror literal raised with its dated rationale line (b80d00b4 precedent). CI-exact local reproduction before pushing: check-test-collection / flake-allowlist / census --expect / ratchet-check / ai-provider-parity / registry --check all 0, the anti-rot gates' own suites 29 passed. Tooling erratum: suppression-registry-gen.py --only <category> DROPS every non-empty other category (first attempt lost ~1900 entries — caught by the per-category count audit, reverted); the full-file regen is the correct invocation. Two process lessons this slice earned. (i) An exit code from a pipeline is not pytest's. A run reported EXIT=0 while its log showed 92 failed, 39 errors — the 0 came from the trailing tail, not pytest. Since then every tier's summary line is captured with echo "PYTEST_EXIT=$?" written INTO the log. (ii) Never run two integration tiers on one Postgres. Overlapping xdist runs deadlocked on the conftest drift-ALTER (deadlock detected, 245×) and produced ~90 FK violations that were cross-worker interference, not code; pgrep -c pytest is now checked before an integration run, and the exclusive re-run reproduced the pre-swap identity (4088) exactly, which is what proves those failures were collisions. (iii) carried from the doc sweep: an agent's self-report of a file edit is not evidence — two agents in the fan-out claimed edits git diff showed never happened (one claimed a code block that exists nowhere in the tree), so every claimed mutation was line-by-line verified against the diff before any of it was kept.

23. Erratum: compose prod.yml's ai-vlm comment claimed a "~6K prompt" worst case that cannot hold (2026-09-27) [V]. The 1.2 row derived the slot from "4 images × ≤1280 + ~6K text + ~1K output ≈ 12.2K", and that arithmetic is right only for a batch of about 90 rows — batch_max_detections ships at 500 (config.py:947), and the repo's own offline token counter measures ~61 tokens per detection row, so a max-size batch is ~30K text tokens before a single image. The slot is still the right size, but for a different reason than the comment gives: the CLIENT now FITS the prompt to the slot (vlm_client._fitted_prompt, d1e279fd) instead of the deployment trusting a hand-computed worst case. Recorded as a dated erratum in the compose comment itself (never a silent spec or comment rewrite, per the doc-vs-repo rule), plus a ledger row here. The general rule this earns: a per-request budget must be computed from the thing that varies (the batch), never from an assumed batch size. Any future spec text quoting "~6K text" inherits this erratum.

24. The vlm-path agent's residency claim was WRONG and is corrected here (2026-09-27) [V]. A parallel agent working the vlm path reported that the OSNet handle is resident at boot as a matter of configuration. It is not, and the check is cheap enough that this row carries it: settings.backend_model_preload defaults False (config.py:2859), so the boot sweep at main.py:1166 does not run unless the operator turns it on; setup.py sets it true only when total_vram_mb > 24 * 1024 (:645, :861), which excludes the 24 GB A5500 (the target hardware is on the wrong side of a strict inequality on its own spec figure). And the preload: flag in a models.yml row is parsed into ModelConfig.preload (model_zoo.py:497) and then read by nobody — the boot sweep filters on enabled and not available, never on cfg.preload, so a row that says preload: true preloads nothing and a row that says nothing preloads everything the flag permits. Consequences, all honest: on the A5500 and on any CPU/sandbox deployment the handle is absent and both the re-ID leg and enrollment answer unavailable — which is the correct degrade by design (vlm_specialists.py:668 names it), not a silent stub, but it is NOT "resident". Measured on this box (CPU, idle): a cold load() ≈ 1.158 s, a warm extract ≈ 0.11 s, and a transient load() releases its weights at refcount 0, so a per-request load is a per-request ~1.1 s, not a free read. What closes it is a decision, not a fix: either the residency policy moves from setup.py's install-time VRAM guess to something the deployment declares, or the sweep gains a real reader for cfg.preload; both are outside M1 and neither is silently patched here. Process note, and the reason this row exists at all: an agent's self-report of repo state is not evidence. This claim was disproved by reading three files; the same fan-out produced two other claims git diff showed never happened. Every agent assertion in this workstream gets a file:line re-check before it reaches a row or a report.

25. Ledger hygiene: this file's file:line anchors go stale within one slice, and one 1.5 verification command never produced the exit code it claimed (2026-09-27) [V]. Re-checked just now, four anchors in the 1.3b/1.5 rows point at unrelated lines after this branch's own growth — reid_service.py:430 (now self._max_retries = …, the CLIP producer moved), face_recognition_service.py:401 (mid-expression), vlm_specialists.py:563 / :610 (now import numpy as np / a session block), config.py:1858 (a closing paren), and enrichment_pipeline.py:3966-3970 (the threat-class set, not the re-ID payload). The VALUES those rows named were re-located and are still correct; only the line numbers rotted. Row 1.5 also claims git grep -n "NemotronAnalyzer(" -- backend/ | grep -v tests → exit 1 (zero prod constructions). That command cannot produce that exit code — the trailing grep -v exits 0 whenever any line survives, and here it does survive (pipeline_factory.py:55, the one intended construction, plus prose in AGENTS.md), so PIPE_EXIT=0 while the claim is still TRUE in substance. The check that actually holds is the structural one in test_pipeline_factory.py. Which leads to the second half: that row names a test class TestNoDirectConstruction that does not exist — the file's real classes are TestPipelineModeSetting, TestPipelineAnalyzerFactory, TestVlmSeamSurface, TestSeamsGoThroughTheFactory, and the assertion lives as test_no_seam_constructs_nemotron_directly (:188). So the behavior IS pinned and the row's prose over-named it. Not re-writing the 1.5 row (dated record, R8); this row is the correction, dated. Doctrine for future rows: name the TEST that holds the property, and if the evidence is a shell command, paste the exit-code capture, not a paraphrase of what the command was meant to prove. This is the same class item 22 already banks (a pipeline's exit code is not the tool's), now with its ledger-copy variant.

26. The null-lie class is not finished: the alerts family is LIVE and still coalesces (2026-09-27) [? — owner decision queued]. 4bc16ebe fixed every reachable site it could reach without a product decision and named the rest; re-counted now on the shipped tree, AlertsPage.tsx + AlertCameraGroup.tsx carry 14 risk_score || 0/?? 0 sites and 5 risk_level || … sites, on a route that IS mounted (App.tsx:262, lazy-imported at :51). This is not laziness and not an oversight — it is a different payload shape (flat alert rows, not events) and its risk-count chips aggregate over the coalesced value, so removing the || 0 there needs a decision about what an unverified alert CONTRIBUTES to a count: its own bucket, or nothing. Same question as the events side got ("Unverified" is a bucket now), but the alerts UI has no badge slot to put the answer in, so the fix is a design call, not a mechanical edit. Explicitly NOT patched half-way. Owner ask: give the alerts family an unverified-bucket rule (or rule it out of scope for Phase 1 and it stays a named follow-up into Phase 3's polish).

27. Three verification-discipline notes from the d1e279fd slice (2026-09-27) [V]. (i) A background tier with a 0-byte log is not a pass. Two background full-tier runs reported exit 0 and wrote empty log files; neither was counted, and the tier was re-run in the FOREGROUND to get a real summary line. The rule generalizes item 22's: the evidence is the printed summary, not the exit code — an exit code with no captured PYTEST_EXIT=/N passed line proves nothing. (ii) A transient xdist worker ERROR is an identity to chase, not a green. The first foreground tier showed an extra ERROR on test_florence_client.py::TestFlorenceUnavailableError::test_error_with_message_only — a pure exception-construction test with no fixtures and no I/O. It reproduced 0 times in 3 targeted repeats (florence + the changed suites under -n auto, 250 passed each), 0 times standalone (128 passed), and 0 times on a clean second full tier (1 failed, 30,433 passed … in 73.51 s, the sole failure the sanctioned env-fail). Banked as a worker artifact under load, with the reproduction counts, so a later session that sees it again has the prior instead of a fresh hunt. (iii) A syntax reading needs the file's actual bytes and the interpreter's version, not a terminal's rendering: this repo runs Python 3.14 (.venv/lib/python3.14/), where PEP 758 makes except TypeError, ValueError, AttributeError: valid without parentheses — the repo's ruff actively normalizes parenthesized except-tuples TO the parenless form, so config.py:1283 and :1413 are both correct. (My own first reading of that line in-session — "Python 2 syntax, or a terminal rendering artifact" — was wrong, and it cost a detour; recorded here so the next reader does not repeat it rather than as a correction to any written note, because none was ever written.) When a hook rewrites something I wrote, the first question is what the tool's own rule is, not how to fight it.

28. The enforcement gate's budget is a per-scene coin flip, and it can open the breaker (2026-09-27) [? — owner decision queued; ledger finding G]. _PROBE_MAX_TOKENS = 400 was sized for the /completion probe, whose grammar is the analyzer schema (4 scalar fields). The shipped CHAT probe sends the full verdict wire schema instead — description, a criteria array, a provenance object — so at 400 the same request echoes the nonce 3/4 times on break_in_attempt (4/4 at 700), pet_activity 0/4 at 400 → 4/4 at 700, loitering ≈2000. Because only ENFORCED is cached (S-1, correct), a scene sitting on the cliff makes a whole replay's enforcement verdict depend on which image the store yielded first. Shipped already, so the floor is safe: a truncated probe now answers inconclusive (never ignored) and the budget-caused failures stopped feeding the ai-vlm breaker — measured before the fix, five verbose scenes opened the breaker and the rest of the corpus was refused WITHOUT I/O, which is finding B's contamination wearing a budget. What is owed is the ceiling (owner-level; it trades probe latency/S4 wall against proof, and a probe-contract change is not mine to make): raise the budget (measured need 700 clears 4/6, loitering ≈2000), OR probe with a minimal probe-only schema — the CI gate proves enforcement with 4 scalar fields, so requiring the model's whole verdict prose to prove a grammar pays output cost for evidence the probe never reads (my read: this one, with the budget raise as its enabler), OR scope the cache to (endpoint, build) as S-2's wording implies rather than (client, first image). The three 2.2 candidate runs keep their numbers (refusals A 2/13, B 1/13, C 0/13, computed on items that answered), but ENFORCED should be read as "enforced on the scene that happened to be first" until one of the three is chosen.

29. The M1 milestone review's biggest finding was two agents inventing code (2026-09-27) [V]. The built-in review of the 13f2d65e..d1a44c62 range (the Phase 2 harness + the new probes) was fanned out to two agents, and each returned a "CRITICAL" set that does not exist in the tree. Agent A's label-contradiction finding cited a file that is not in the repo (build_gen2.py — build_gen2 is a function at eval_store.py:546), a field the schema has never had (EvalItem at assess_input.py:40-51 carries expected_label/expected_risk_score, no expected_min_level; git grep expected_min_level -- backend/ is empty), and eval_store.py:268, which is the synthetic label-set path, not the stock one. Agent B's two criticals described an order the code does not have: enforcement.py:144-149 returns INCONCLUSIVE "HTTP {status} - not measurable" on a non-200 — not IGNORED, which is a body judgement reserved for a complete reply without the const — and its const-echo check at :154-158 runs BEFORE the truncation branch at :166 (echo → ENFORCED is finding A's pinned order, with a comment naming it), so the whole "budget converts ENFORCED to IGNORED" scenario cannot occur. Its tool_calls.py:207 "no /props gate" claim is off by eight lines from a /props block that starts at :188. What the review did find is one minor, real, non-defect: s_metrics.s2_false_positive_rate counts the benign arm's refusals in refused and reports them beside the rate, so a refuse-everything model shows fp_rate 0.0 and needs the adjacent field to read as an escape (its own docstring says "has not passed S2, it has escaped it", and the bake-off report quotes refusals in the headline). Kept as a reporting-shape observation for 2.2's report generator, not a code change — the harness is honestly labelled already. The agent's follow-up claims went the same way, all checked against the code: S5 "crashes the report on a stored NULL-score row" cannot happen — compute_report takes the in-memory rows replay_item builds, and both of its paths set verdict and risk_score (the refused path writes verification_failed/None explicitly, and s5_refusals uses .get); "refusals hide inside S3 as misses" is REAL but safe-direction — a refused incident is counted not-a-hit, so a refusing model is scored worse, never better, and the refused count is its own reported field beside it; the tool-probe's "SUPPORTED without an arguments check" inverts :150-155, which compares the parsed token to the nonce, and its except: pass on malformed arguments yields args=None, which then fails exactly that comparison. The one thing worth KEEPING from the review is the S2/S3 reporting asymmetry above, plus a candidate-level run_manifest.json (endpoint, build, budget, corpus gen per run) for 2.2's report generator, and — this is the meta-finding for how reviews get run here — an agent-reported "critical" in this repo has now been wrong 8 for 8 across two agents, so the rule this review earned is that a finding is only ever acted on after its file:line is opened: item 24 said don't trust an agent's claim; this review says treat the CRITICAL label itself as the least trustworthy part of the report. Nothing in the harness changed as a result of the review.

30. Item 29's rule earned its keep twice: the full-file pass over the same range found eleven findings, nine are real, and they shipped red-first (2026-09-27) [V]. Item 29 ended "nothing in the harness changed as a result of the review" — true of the fan-out, wrong as a closing word, because the same 13f2d65e..d1a44c62 range then got the pass the fan-out skipped: reading the files whole. Eleven findings; every one was opened at its file:line before being acted on (item 29's own rule) and nine survived that check — the CRITICAL-label rule held in both directions. Fixes at 8ad70693, red-first: stashing the three implementation files makes exactly the 11 new pins fail on pre-fix code, 272 evaluation-tier tests pass after. The nine, each its own null-lie or unprovable-claim class: ① the control freeze writes expected_label="" for an unlabeled event (control_freeze: label or ""), and S2's skip keyed only on a MISSING key, so an unlabeled item left BOTH bar denominators with nothing counting it — a 13-item run measured 9 and no field said so (S2's skip now counts "" like absence; S3 grew unlabeled); the repo's core class, at its own eval reader. ② S5's bar is "0 UNPARSEABLE verdicts" (spec :77) but all five error classes collapsed into one count, so 13-of-13 schema failures and 13-of-13 connection refusals both read refusals: 13; s5_refusals now aggregates the class name replay_item already stores (by_error_class / unparseable / unavailable / unclassifiable — class names, aggregate, D10-safe, no new import: the module stays a leaf). ③ Wilson endpoints unclipped — hi=1.0000000000000002 at 76 of n<300 (incl. S3's n=285), negative lo at 21; clamped, and the interval test now asserts the unit interval because the old lo <= p <= hi assertion PASSES at 1.0000000000000002; the 0-of-20 pin stopped re-running the implementation's own closed form inside the test and got longhand numbers. ④ each S3 bucket now carries its own unfailable count — the shipped stock S3 of 0.875 sits on a denominator where every scored row hits by construction, and the prose said so while no field did. ⑤ --limit 0 completed a full report over zero items, --limit -1 silently dropped the last item; both refused, matching how this module already refuses a media-less generation. ⑥ naming an endpoint alongside an injected client factory echoed a URL the run could not verify it called — and the test COMMENT claimed that invariant while pinning its violation; the combination raises now, injected runs report vlm_url=None, source=injected. ⑦ p95 was latencies[int(n*0.95)], one rank high at every whole-multiple n (n=20 reported the max); nearest-rank ceil(0.95n) now — and the finding's own overstatement was caught during verification ("p95 == max for every n ≤ 20" is wrong AT n=13, where both formulas legitimately give rank 13), so the bake-off's S4 figures stand, no retraction rides on this (the report's dated note says so). ⑧ the report gained corpus identity (store dir name + counts + label mix, paths and item ids never) per plan 2.1.5, and main() closes the store in finally. ⑨ three test repairs: a substring assertion that pinned nothing became the row-shape set-equality that is the actual regression risk; the ladder pin asserts ConstrainedDecodingNotEnforced is IN _DEGRADABLE_ERRORS instead of that some import exists; and plan 2.0.2's claimed-but-absent "build never opens a gen-1 path" pin became real — spy EvalStore, a gen-1 file staged beside the target, size compared after. Not patched, deliberately: the S2/S3 refusal asymmetry stays kept-as-ruled from item 29, now with machine-readable backing; and ⑩→open-issue queue: S3's floor derives from the band MIDPOINT (levels.floor_for_expected_score, D-P2-2's own ruling) while the corpus declares a MINIMUM. Measured over the shipped corpus, incident-capable sets only (benigns never reach S3 — my first pass over all 413 label sets mixed in the 214 equal-benign cases and read as a two-sided spread; it is not): the midpoint-derived floor is STRICTLY ABOVE the declared minimum on 117 label sets, equal on 160, below on 0 — S3 is harder than the corpus's declared minimum on 42 % of the incidents it scores, never easier, safe-direction but a measurement the owner chose by ruling, not by arithmetic. Changing the derivation changes what S3 measures against a frozen store — owner's call, queued. The finding the owner's own question turned into a store-query: asked "what class were the bake-off refusals?", answered from the eval DB, not inferred — candidate A (896a4c2b) refused TWO items: stock:break_in_attempt → ConstrainedDecodingNotEnforced (what the bake-off report saw) AND stock:vehicle_parking → VlmSchemaError (a real unparseable the pre-fix harness could not name) — the bake-off report's S5 row for A under-counted A's unparseable by one, and the report carries the dated erratum (its prose "the probe's ONE refusal" says one; there were two). B's single refusal is the enforcement artifact (0 unparseable), C none. Gate identities, each from its own captured log on the committed tree: unit -n auto → 1 failed, 30544 passed, 124 skipped, 8 xfailed (/tmp/unit_item30_tier.log, sole failure the sanctioned systemctl env-fail) — a correction of my own: 8ad70693's message quoted 30,545 from an uncaptured run, and item 22's rule ("the evidence is the printed summary") cuts both ways, so the log-truthable number is 30,544 and stands. Contracts -n0 --timeout=30 → 646 passed, exit 0. Integration, live PG :5433 + Redis :6380 connect-checked IN THE SAME SESSION before the run (psycopg version line + redis PONG logged): 4089 passed, 107 skipped, 2 xfailed, PYTEST_EXIT=0 written into /tmp/integration_item30_final.log; an earlier capture of the same identity (4089) predated the commit and lacked the exit-code line, so the tier was re-run on the tree the ledger cites. gen-ai-contract.py --check current; suppression ratchet 0. And the meta-lesson item 29 already states, restated because this slice proved the failure mode is two-sided: a fan-out review can invent defects at scale, and a full-file review can miss them just as silently — the fan-out's 8/8 fabrication rate and the full-file pass's 9 real findings are the same range, and no pass was optional.

31. Step 0 (branch hygiene): github/main merged in, tiers re-proved — and the banked unit identity turns out not to be a single identity (2026-09-27) [V]. The merge is e62aa86b, and it is a MERGE and not a rebase for the reason the goal names: #6681 landed as a squash (4bfd6fa4), so the branch's 75 commits are absent from main by identity while main holds one commit absent from the branch — rebasing would duplicate the content; merging is the only shape that converges. git diff --stat e62aa86b^1 e62aa86b printed nothing, so this step is a verification and not a repair, and the next PR's diff is its own work rather than 75 already-merged commits. The tiers on the merged tree: contracts -n0 --timeout=30 → 646 passed, exit 0 (/tmp/contracts_step0.log); scripts/gen-ai-contract.py --check current; unit -n auto green modulo the sole sanctioned failure test_skips_when_skip_build in every run — but three runs, three different identities: banked 1 failed, 30544 passed, 124 skipped, 8 xfailed (/tmp/unit_item30_tier.log), then 30545 passed / 123 skipped (/tmp/unit_step0.log, /tmp/unit_step0_rs.log), then 30543 passed / 124 skipped, 1 error (/tmp/unit_step0_rs2.log). I refused to call that noise, and diffing the two -rs skip lists (comm over the SKIPPED [...] lines, 111 vs 112 entries) named the ±1 mover exactly one line deep, with a mechanism that makes the pass the wrong answer, not the skip:

32. Drift ① — TestTensorboardImportHazard::test_real_module_wins_when_importable (test_osnet_loader.py:1357-1361) asks a question sys.modules cannot answer. It decides "is the REAL torch.utils.tensorboard importable here?" by calling importlib.import_module("torch.utils.tensorboard") — but _ensure_tensorboard_importable() inserts its inert stub into sys.modules and never removes it (osnet_loader.py:114-131), so once any earlier test in the same xdist worker has exercised the torchreid path (item 22's TestRealWeightsProof does, at :1394), the import succeeds and returns the stub. real is then the stub and the test's own assertion sys.modules[...] is real is vacuous — it proves nothing while passing. Proven two ways, not inferred: the skip-list diff (that one line moved skipped→passed and nothing else moved), and a direct probe in an env where tensorboard is definitively NOT installed — after _ensure_tensorboard_importable(), importlib.import_module("torch.utils.tensorboard") returns a module and is-compares equal to the stub (is-stub: True). So the test's skip path is destroyed by worker ordering and its pass path is unfalsifiable whenever it runs. Fix shape, red-first, in item 1's blast radius (it is the loader item 1 touches): the gate must ask about the tensorboard package, not about a torch.utils submodule the shim may have filled, and the loader's stub — which is correct in production, where it is the only way torchreid imports — must not be the thing a test trusts.

33. Drift ② — an xdist-order-dependent teardown ERROR, RuntimeError: Event loop is closed. test_florence_client.py:52's reset_global_client fixture → reset_florence_client() (florence_client.py:1630) → .close() (:395) → httpx → httpcore → asyncio.selector_events:1216 close → base_events:550 _check_closed raises, surfacing as ERROR at setup of TestCircuitBreakerIntegration.test_circuit_breaker_uses_config_settings — a test whose subject is not the Florence client at all. The file was last touched by 610882b4 (2026-09-22), so it is not fallout from this merge; it is a shared-client teardown racing a worker's already-closed loop. Same fix family: close the client before the loop dies, or don't close a client the fixture didn't open.

34. What I did NOT do: no product code rode on this. Both are test-isolation defects, neither is a shipped behavior, and the sanctioned-failure identity held in all three runs. But the honest restatement of the gate for every later slice is now narrower and has to be said out loud: "1 failed, 30544 passed, 124 skipped, 8 xfailed" is not a stable identity on this repo — it drifts by ±1 skipped with xdist ordering (①) and can carry +1 error (②). The claimable invariant is no failures other than the sanctioned test_skips_when_skip_build plus a named reason for any count movement, which is what item 27's "the evidence is the printed summary" was always reaching for. Restoring a truly stable identity is the two fixes above, and they land with item 1 rather than as a drive-by.

35. Item 1 RESIDENCY FIX shipped red-first — closes item 24 by pointer (2026-09-27, owner ruling ">= + cfg.preload reader") [V]. Item 24 ended "what closes it is a decision, not a fix"; the owner decided the shape, and the fix is small because the decision carried it. The defects, re-derived from the tree before touching it (item 25's anchors may have moved — they had: vlm_specialists.py is 948 lines now, not 1044): (a) config.py backend_model_preload defaults False; (b) setup.py computed model_preload = total_vram_mb > 24 * 1024 in three byte-identical inline copies — strict >, so a 24576 MiB card lost on its own spec figure; (c) main.py's sweep filtered cfg.enabled and not cfg.available — and available flips True only AFTER a successful load, so at boot it selected every enabled row with the flag on and nothing with it off, while cfg.preload was parsed and read by nobody; (d) every description along the way ("Eagerly load all AI models", "load all enabled") described a mechanism none of the three sites implemented. The fix: one should_preload_models(total_vram_mb) in setup_lib/nvidia_detect.py (where GPU knowledge already lives) with the INCLUSIVE threshold and a PRELOAD_MIN_VRAM_MB constant, replacing all three inline copies (a pin asserts no inline > 24 * 1024 survives and that all three mode functions call the helper); select_preload_candidates(model_zoo, *, preload_enabled) in main.py as the single row-selection point (enabled AND cfg.preload AND not available), called by the lifespan sweep; osnet-ain-x1-0, face-detector-scrfd, face-recognizer now declare preload: true with comments naming F11 — those three are exactly the rows whose handles are read from the manager registry by membership (get_reid_handle, get_face_leg_handles, which needs BOTH face rows); the plate leg deliberately stays out (it self-loads via fast_alpr_loader/the optional [alpr] extra, not the zoo). smoke-fire-yolov8n already declared preload: true and now means it. Config field, .env comment and the models.yml legend rewritten to describe what the code does. Two findings the [V] driver earned, both ledgered-not-fixed (scope honest): ① face_recognizer_loader and smoke_fire_loader have no NEM-4501 validate_model_path call at all — osnet's loader does, and it refused my dev-box zoo root ($AGENT_GPU_DIR/models/model-zoo isn't under the security.py:41 allowlist; the shipped root /export/ai_models is, and test_osnet_loader.py:1400-1409 already documents exactly that dev-vs-shipped posture). The asymmetry means the face rows load weights through unvalidated paths today; it predates this change, and adding validation there is its own red-first slice, not a drive-by inside this one. ② never_evict/priority are still honored by nobody — the model zoo has no eviction pass at all (grep: no def *evict* outside tests); the legend now says so instead of promising it. Red-first, 14 pins, first draft /tmp/item1_red.log: 7 in test_nvidia_detect.py (helper exists; 24576 is True; 24575 False; above True; 0 False; two-12-GB cards sum True; no inline copy left), 4 in test_main.py (flag off ⇒ []; flag on ⇒ only preload rows; already-available row not reselected; the lifespan calls the helper and the old predicate is gone from the source), 3 in test_model_zoo.py (the F11 rows declare preload true; the shipped zoo through the real parser selects exactly the declared rows — derived from the yaml, not a hand-copied list, because my first version of this pin asserted a literal that reality contradicted the moment I ran it: smoke-fire's loader registers here, so the shipped set is four rows, and the test comment now records that) plus flag-off-on-real-zoo ⇒ []. All 11 first-draft tests failed on the pre-fix tree before any implementation existed. The [V] driver (/tmp/item1_driver.py, real loads, CPU legs): flag off ⇒ selected: [], reid_handle_resident: false, face_handles_resident: false, registry 0 — F11 reproduced on this box; flag on ⇒ selected the four declared rows, reid resident with model_id osnet-ain-x1-0@osnet_ain_x1_0_msmt17@8a07e8da3894 (byte-identical to the shipped suite's OSNET_ID pin at test_osnet_loader.py:1163 — the sha-enforced belt survives the boot path), face handles resident, registry 3, whole sweep 1.37 s; smoke-fire errored honestly (weights absent on this dev box — F12's degrade: sweep warns, boot proceeds, the other three loaded). That is the ~1.16 s cold-load-per-request answered once at boot. Gate identities from captured logs on this tree: unit -n auto -p no:randomly → 1 failed, 30559 passed, 123 skipped, 8 xfailed (UNIT_EXIT=1, sole failure the sanctioned test_skips_when_skip_build; arithmetic exact: 30544 + 14 new + 1 known tensorboard skip→pass = 30559, 124 − 1 = 123 — item 31's drift, named, not smoothed); contracts -n0 --timeout=30 → 646 passed exit 0; gen-ai-contract --check current; integration with PG/Redis connect-checked in-session (psycopg 16.15 line + Redis PONG logged before the run) → 4089 passed, 107 skipped, 2 xfailed, INTEGRATION_EXIT=0 — the identity held even though the integration tier boots the app and exercises the changed lifespan. Gate churn: ruff auto-collapsed one signature line, detect-secrets re-baselined one pre-existing models.yml entry's line number (111→116, my legend edit shifted it; no new detection) — re-staged to zero churn, 17 hooks pass. Process correction recorded where it belongs: item 29's rule turned out to describe me during this same slice, twice — I drafted a main.py docstring for a helper I had not yet written (the Edit failed loudly; caught because I re-read the diff instead of trusting the plan) and I "fixed" three ledger item 1 references that named an item that doesn't exist (now 32). The step-0 invented-commit-hash incident (a "pushed as 13945107" claim for a commit that never ran) is disclosed the same way — the rule "open file:line before acting" applies to my own assertions, not just subagents'.

36. Item 2 SYNTHETIC-EVAL INTAKE: the born-labeled contract is pinned at our boundary, and the corpus directory is now the label's ONLY authority (2026-09-27, code bae92f47) [V]. The parallel agent builds the generator; the freeze/replay side is ours, so what this slice owns is the DOOR — what a batch must look like to enter, and what refuses. Three defects, all measured on the tree before touching it. 15 new pins total; 9 demonstrated red before their implementation (/tmp/item2_red.log: 6 failed / 5 passed on the pre-fix tree — the 5 greens are guards that prove a refusal does not overreach: no-declaration-still-uses-placement, agreeing-declaration-accepted, the full 413-set corpus still loading, the D10 raise-not-skip, count-identity; +1 red = the specialist pin; +2 red by guard-removal, below).

    • Defect ① — a label could be flipped by the file that carried it. load_synthetic_items resolved expected_label as _CATEGORY_LABELS.get(labels.get("category", category), category): the SET'S DECLARATION was the lookup key and the directory was only a fallback, so a set placed under threats/ declaring "normal" froze benign (probed: synthetic:threats:set_a -> benign), and a placement outside {normal, suspicious, threats} made the DIRECTORY NAME the label — "threats" is not a value any reader counts, and m0_size_report correctly reports such rows as unknown on neither side. import_generated_items (:452-454) carried the same conflict bug behind a comment claiming parity with the loader, and its unknown-placement case SKIPPED — a batch the generator mis-folded into one wrong directory imported as zero items and read as an empty-but-green run. Measured first: of the 413 committed sets 366 agree, 47 declare nothing, 0 conflict, 0 out-of-vocabulary, so refusing is free.
    • The fix — resolve_category_label(placement, declared, *, origin) in eval_store.py, the one authority both doors call. Placement rules; a declaration may CONFIRM it; a conflict or an out-of-vocabulary name raises naming BOTH sides ("sits under 'normal' but declares category 'threats'") — "bad category" alone is not actionable by whoever generated the set. import_generated_items converts that refusal to LabelImportError, which is already this importer's shape for a misconfigured run (its D10 branch), so a disagreeing corpus aborts instead of landing in a manifest as a loss. Why refuse rather than pick a precedence: a flipped label is invisible downstream and bends the S2/S3 denominators — an incident counted benign deflates the exact side S2 ranks incidents against. Same two-sources-of-truth shape as item 24, same resolution.
    • Defect ② — the door the parallel agent's batch actually uses dropped specialist_outputs. load_synthetic_items and load_stock_items both render a declared specialist_context through the shipped renderer; import_generated_items — the MEDIA-bearing, born-labeled path — built its AssessInput without the field. build_gen2 refuses a generation where zero items carry a rendered block ("the replay measures a system 1.3b did not ship"), but that guard lives on the builder, and this importer writes straight into a store: the same corpus, same replay, opposite outcome depending on the door, silently. Now both doors call _render_specialist_outputs; pinned by freezing a set that declares a person_reid match and reading "DryRun" back out of the STORED item.
    • Defect ③ — attribution is now required beside every frame, not asserted by the generator's report. The shipped writer already works this way (scripts/synthetic_media.py writes one attribution JSON per frame; load_stock_items documents the same for stock), so the intake contract matches it instead of inventing one: _attribution_gap skips a set LOUDLY when a frame's sidecar is missing, unparseable, or lacks license+artist — a 0-byte sidecar is a MISSING one wearing a filename, which is item 27's rule applied to attribution. Loud skip rather than refusal because the size bar below already turns a wholesale-missing batch into a failed gate, so the per-set loss stays visible in the manifest without aborting a run over one bare set. (The load_stock_items docstring promises attribution "not inside the item"; until this slice nothing ENFORCED it on the generated path.)
    • Count-identity block. m0_size_report was already honest (out-of-vocab label → unknown, counted beside the bar, never laundered as "unlabeled") — the loader was the bug, and the pin now says so directly: 100 benign + 20 incident + 50 "threats"-labeled rows reports (100, 20), unknown == 50, unlabeled == 0, and the three buckets sum to 170. That is the property the bar rests on: a batch of 100 mis-labeled items must never read as 100 benign.
    • Why the bars cannot rank (the goal's point, verified not repeated): the Phase 2 bake-off table (docs/plans/2026-09-27-vss-phase2-bakeoff-report.md) ran every candidate at S2 n=5 and S3 n=8 — Wilson intervals [0.000, 0.434] and [0.529, 0.978] for identical 0 %/0.875 readings, i.e. three candidates indistinguishable because the media-bearing set is 13 items. The >=100 benign / >=20 incident bar is what turns those denominators into measurements; the dry-run above is the first batch that would satisfy it.
    • The [V] DRY-RUN, one batch end to end through the shipped functions only (/tmp/item2_dryrun.py, /tmp/item2_dryrun_final.log, aggregate output only — D10). 124 born-labeled media-bearing sets (100 normal / 24 threats), off-repo under $AGENT_GPU_DIR/out/eval-store/item2-dryrun (corpus_root_is_off_repo: true), each frame carrying an attribution sidecar; FROZEN by import_generated_items (attempted 124 / imported 124 / skipped 0, every_row_born_labeled: true, media_is_frames_only_not_sidecars: true — the manifest's attribution rows are copied into the manifest, the sidecar JSONs never become media), REPLAYED by run_replay through the shipped make_client seam (vlm_replay.py:52 FakeClient pattern; vlm_url_source: "injected"), client answering by request.image_paths[0]. Result: m0_bar benign 100 / incidents 24 / m0_complete true; specialist 124 of 124 frozen items carry a rendered person_reid line; replay n_items 124, S2 denominator 100 (fp_rate 0.0, refused 0, skipped 0), S3 n 24 (recall 1.0), 124 stored results rows, 124/124 requests carried the specialist block, client closed once; count_identity.all_agree: true (importer labels == store payloads == the replay report's corpus.labels == m0_size_report); negative leg: a normal/ set declaring "threats" → {"refused": true} with both sides named, and the good store untouched at 124 items. The S2/S3 numbers come from a SANE fake oracle — this leg proves plumbing and denominators at scale, not a model; the real numbers are the GPU rows. Note this is a DRY-RUN artifact under the off-repo eval root, not a generation: it is not gen-3, and no report was committed with it.
    • Blast radius, measured: import_generated_items and resolve_category_label have zero importers outside backend/evaluation/ and its tests (grep: no app module imports evaluation.eval_store / evaluation.label_import at all), so no shipped request path changes behavior; the eval tier is the surface, and the full unit tier is the gate anyway. The tests/unit/evaluation/_make_corpus fixture now writes a sidecar per frame — it stands in for the generator's output, so making it match the shipped writer is the honest move (that is what turned the attribution pins red: with the guard removed they fail 2 failed, 6 passed, restored → green, verified rather than assumed).
    • Gate identities from captured logs on the committed tree (bae92f47): unit -n auto → 1 failed, 30574 passed, 123 skipped, 8 xfailed, UNIT_EXIT=1, sole failure the sanctioned test_skips_when_skip_build (/tmp/item2_unit_final.log; arithmetic exact — item 1's tree printed 30559, +15 new pins = 30574; the skipped count is item 31's named ±1 drift); contracts -n0 --timeout=30 → 646 passed, exit 0 (/tmp/item2_contracts_final.log); scripts/gen-ai-contract.py --check → "AI contract is current", exit 0 (no ai_contract surface moves — this slice touches only offline eval tooling); the eval tier itself: 287 passed, 3 skipped (/tmp/item2_eval_tier.log). Integration was NOT re-run: nothing this slice changes is reachable from the app (the grep above), and I am not claiming a tier I did not run.
    • Item 27's rule caught me again, from the timing side [V]. The first rerun "on the committed tree" launched while two behavior-neutral edits (a docstring truthfulness fix — it claimed a license reading "unknown" would be rejected when the code only checks truthiness — and an unused-parameter cleanup) were still landing; its unit log printed 11 failed, ten of them in test_label_import.py, because the workers imported the module mid-rewrite. stat named it: log finished 15:03:05, commit landed 15:03:30 — the log tested a tree that never existed as a commit. The identities above come from a rerun launched AFTER the commit with a clean git status; had I pasted the racy one, I would have disclosed a failure that was an artifact of my own timing. New memory: freeze the tree first, prove second; compare a background log's mtime to the commit time before citing it.
    • Issue 19 stays [O] and this slice is the reason it can close when the corpus lands. Item 19's sharpest restatement is this file's finding D: the media-bearing sets and the specialist-context sets are DISJOINT — 13 media-bearing items carry 0 rendered blocks, the 5 with blocks carry 0 media — so the shipped wire could never exercise the specialist prompt. The three fixes above are what let a real batch fix that in one freeze: born-labeled, media-bearing, attribution-carrying, and specialist-declaring AT THE SAME TIME, with the labels refused rather than guessed if the generator ever disagrees with itself. Until a real corpus arrives, 19 remains open and the numbers above are contract evidence, not measurements of the world.

37. Item 3 LARGER-MODEL SURVEY: past-12 B answers the goal's question with a no, and the survey caught a build bug worth more than its own rows (2026-09-27) [V]. Two candidates ran through the bake-off's own harness — same frozen gen-2 n=13, same run_replay, config-matched (CTX 32768 / PARALLEL 2), GB300 through agent-gpu, aggregate-only (D10) — and both rows live as a dated ADDITIVE erratum in the bake-off report (Erratum 2, table E/F); the A/B/C/D table is untouched, exactly as the goal required. No code changed this slice: the survey's deliverable is measurements and one defect localization. What they are, in the order that surprised me:

    • The fit headline is HALF wrong in the goal's own words, and the wrong half matters. Measured at VLM-only residency (an S1 estimate — F13 reserves S1 itself for 24 GB hardware, spec :387): Qwen3-VL-30B-A3B is over the 20.4 GiB bar (broker actual 22688 > 20889 MiB), but Mistral-Small-3.2-24B fits it — 20274/20680 actual, leaving only ≈210–615 MiB. "Nothing past 12 B fits" survives only as the full shipped stack (detector + specialists + VLM — S1's own definition, measured on neither here, F13), and a margin that thin cannot carry it; the honest sentence is in the erratum, and the A5500 run (2.3, owner-run) is what settles it. The MoE geometry finding came free: the 30B spends 3072 MiB KV at the same ctx/parallel where A/C spent 4608 — B's hybrid-class KV relief has company.
    • Finding ① — b7972's response_format: json_schema path fails against the Mistral GGUF at ~75–100 %, and my first F row WAS that failure, not the model. The first replay returned 13/13 refused: 5 × ConstrainedDecodingNotEnforced, then the shipped breaker OPEN swallowed 8 as VlmUnavailableError (run 0123c66c — kept, labeled an artifact, never counted). Localized with the endpoint still up: the 500 (Failed to parse input at pos N, string lives in the server binary) fires on json_schema requests with or without an image, at PARALLEL 1 or 2, while plain / json_object / the same grammar sent directly ran 6/6 clean; the same weights on ai-vlm:sm103-b11090 (B's already-shipped image) answered 8/8 clean, and the scored F row ran there. Item 29's doctrine applied to my own probe set: the enforcement probe's lone ENFORCED pass had slipped through the same ~25 % window the s2 arm-B kept missing — intermittency is why a one-shot probe is not a line; three s2 repeats (ENFORCED / INCONCLUSIVE / INCONCLUSIVE) named it. Follow-up named but not chased: which llama.cpp commit fixed the server-side response_format→grammar translation (F is the first llama-arch GGUF this harness ran; A/B/C on their builds never trip it, so no shipped path changes today).
    • Finding ② — "does past-12B earn its keep?" measures as NO, on the budget axis. E: 9 of 13 replies hit the shipped 700-token verdict budget stop='length' (finding A's class at model scale — a bigger model writing a LONGER verdict answers the same wire WORSE; break_in_attempt's ladder gets a third shape: over-budget on its own, not just at the probe cliff), mix 3 rejected / 10 failed. F answered fast (median 3788 ms — the fastest of all six candidates) and hedged: 11/13 uncertain, S3 0.875 [0.529, 0.978]. Tool probes SUPPORTED both arms on both; S5 broken_rows: [] on both — the client classified every failure, nothing laundered.
    • The criterion-differentiation read: the goal's parenthetical is TWO measures compressed, and only one reproduces. The "7/11" recipe was never written down (repo + off-repo artifacts searched — not found), so the erratum states the recipe instead of citing the number; the driver persists at $AGENT_GPU_DIR/out/eval-store/gen-2/tools/crit_diff.py. m1 (answered items with exactly ONE criteria row): A 7/11 — the goal's number reproduces exactly; C 7/13, B 0/12, E 1/3, F 9/12. m2 (≥2 criteria, fewer distinct evidence strings than rows): A 1/11, B 1/12, C 0/13 — "differentiated all" is an m2 statement. Read together, differentiation does NOT rank by size: the 4B's headline 7/11 is m1, under which the 8B (7/13) and the 24B (9/12) answer single-criterion just as often, while m2 is near-clean for everyone at n=13 — it separates nothing the report's own grammar-floor non-claim (F14) doesn't already forbid.
    • The "all five architectures register" claim, restated as measured: four GGUF-expressible archs (qwen3vl, qwen3vlmoe, nemotron_h, mistral3) REGISTERED — by string in libllama.so of ai-vlm:sm103-v12. The first check (grep the EXECUTABLE) said ABSENT for all four, contradicting run C's own history — the registry lives in the shared library, not the binary; open the artifact before opening the conclusion (item 29 again, this time against my own grep). The fifth (Cosmos-Reason2-8B) can't even be read: config.json gated 401, no GGUF — D's BLOCKED stands.
    • Two of my own readings that were wrong before they shipped, both caught by opening the source: (1) the Mistral 24B "text-only" hypothesis — formed from an empty pipeline_tag + no vision-tagged search hits; the model card, config.json (Mistral3ForConditionalGeneration + vision_config) and three mirrors' mmproj-* files killed it. An empty metadata field is absence-of-metadata, not a measured absence. (2) a backgrounded pull's "completed exit 0" notice fired while its child curl still had 97 % to go — the completion signal is the log's PULL30B_DONE marker, not the launcher's exit; same lesson family as item 27.
    • Disk was a first-class constraint, not an afterthought: 29 G free against 32.1 GiB of survey weights ⇒ the legs ran SEQUENTIALLY, each weight set fetched, measured, deleted, re-fetchable at the ledgered URLs; bake-off A/B/C weights untouched. Byte counts as fetched (exact HF-reported sizes; /tmp/pull30b.log, /tmp/pullmistral.log): E Qwen3VL-30B-A3B-Instruct-Q4_K_M.gguf 18556687168 + mmproj-Qwen3VL-30B-A3B-Instruct-Q8_0.gguf 712148928; F Mistral-Small-3.2-24B-Instruct-2506-Q4_K_M.gguf 14333922848 + mmproj-F16.gguf 878053568. Provenance per F's lineage: no official GGUF exists for the Mistral row — mirror-converted (quantized_by: Unsloth), header arch llama, no license key in the header; apache-2.0 from the model card. Two provenance hops where A/E need one, ledgered in the erratum rather than smoothed over.
    • Identities: runs E e4ea8bbd (b7972), F-artifact 0123c66c (b7972, refused-all), F 90ed4690 (b11090, the scored row), all commit-pinned d3794497; reports gen-2/reports/2.4-survey-{qwen3vl-30b,mistral-24b,mistral-24b-b11090}.json. Teardown verified: agent-gpu ps → containers: []; models dir back to the bake-off's six files. Gates: this slice is docs-only (erratum + this item) — no code surface moved, so no pytest tier is claimed; git diff before commit showed exactly the two doc files. Issue 19, the M2 pick, and the S2_MAX/S3_MIN settings are untouched and remain owner-owned: every number above is a GB300 indicative reading (F13) and never a bar verdict (F14).

38. M2 PROVISIONAL PICK — Qwen3-VL-8B-Instruct Q4_K_M is the shipped serving VLM (owner ruling 2026-09-28) [O]. Owner, verbatim: "lets go with Qwen3-VL-8B for now. we can revisit later if needed." This is the M2 decision the spec's D5 reserved for the owner and the bake-off report declined to make for them; provisional is the owner's own framing (for now / revisit later), kept rather than hardened into a permanent choice. Nothing in the A/B/C/D table, the report's non-claims, or any S# row was edited — the corpus ordered nothing and this item does not quietly retire that.

    Rulings (three, each from the same exchange, each quoted):

    1. Flip the shipped default, not record-only: "flip the shipped default" — so the identity moved as one atomic commit (54141d9c) across its five spellings: .env.example VLM_MODEL_PATH/VLM_MMPROJ_PATH/VLM_MODEL_ID, docker-compose.prod.yml MODEL_PATH/MMPROJ_PATH/MODEL_ALIAS/backend VLM_MODEL_ID, and Settings.vlm_model_id + its description. A name that drifts between these sites is the 2ea790bc silent-config-gap class and the degraded-path label is the one that lands in event_verifications.model_id when a vlm call FAILS — a label naming a model that was never serving is an F11-class provenance lie on the incidents board.
    2. Record it as spec rev 7 (not ledger+erratum only): rev 7 prepended in the house formula, D5 row gains a **Rev 7:** sentence with prior text intact, M1's exit test and the §8 checklist VLM line name the new smoke model, §5's "The owner picks." carries the outcome. The §5 candidate list is NOT rewritten — it is the historical set that ran. A finding this ruling surfaced: M1 is still OPEN (its assertions 2/3 are the owner-run A5500 bring-up), so M1's line was worded to name what the run will execute on, explicitly not something achieved — writing "8B" there plainly would have made the spec claim a milestone closed on a model it never ran.
    3. 8B primary, 4B as a measured fallback row: so the A5500 handout (regenerated from scripts/a5500_precheck.py, never hand-edited — every string in it is script-derived) now says serve the 8B, take its S1 peak, then take the same reading on the 4B pair. Two readings because an 8B fit failure must abort onto a model that already has a number on that box, not into a re-run.

    The weights pin, taken with the claim rather than after it: Qwen/Qwen3-VL-8B-Instruct-GGUF — Qwen3VL-8B-Instruct-Q4_K_M.gguf 5,027,784,800 B sha256 67d1659bfe71b89d50b45a4ad1a9e5b997e5bb16ce5da66a6a6167abd569e9e2; mmproj-Qwen3VL-8B-Instruct-Q8_0.gguf 752,289,728 B sha256 c6ba85508d82f42590e6eb77d5340369ab6fecf107a7561d809523d8aa5f3bfd. Re-sha256'd twice this session, once immediately before writing them into two durable docs. Both already on the share, mode 644 (finding F's read bit in place), so no fetch gated the flip. No model-zoo row can carry these — models.yml is the Triton/enrichment set and has no serving-VLM row for any candidate, so the pin lives here and in the Brev checklist rather than on the sha256: mechanism the face rows use; named so nobody goes looking.

    The GGUF-header proof that the pick does not buy KV relief (parsed this session, both files): block_count 36, attention.head_count 32, context_length 262144 identical for 4B and 8B; only feed_forward_length moves (9728 → 12288). So the report's "same shape as A" line is right, the 8B's cost is weights/activations and not the KV pool, and VLM_CTX_SIZE/VLM_PARALLEL needed no change. Fit readings quoted from the bake-off report and nothing else: 8B vram_actual_mib 11216 (9376 projected), 4B 7285 MiB projected (fit log) — and the 4B has no broker-actual in that report, which is itself a reason to take both readings on the A5500.

    The flip conditions, written falsifiable while they are fresh (each is a measurement that reopens the pick, not a mood): (i) 8B fails S1 on 24 GB hardware ⇒ fall to the 4B pair, already the handout's fallback row, so no re-run; (ii) KV density turns out to bind stream count ⇒ Nemotron-Nano-12B-v2-VL reopens ahead of both (its KV is 768 MiB — 6 KV layers of 63 — against our 4608 MiB, 36 of 36): the one axis where a candidate beat the pick on measured evidence, and it beats the pick on a bigger model too; (iii) post-item-19 corpus S3 < S3_MIN 90 %, or candidate C's uncertain rate 0.231 (report :33, :123) proves to be a real hedging prior rather than 13-item noise ⇒ the pick reopens.

    Explicitly NOT adopted: no S#/D# text change beyond rev 7's identity sentences; the uncertain spread stays a 13-item hint; no candidate-D unblocking; no reid/specialist/residency change (this pick is the serving VLM only — PIPELINE_MODE=vlm, GATEWAY_MODEL_SET=vlm, the ai-vlm image pin and b7972 all stand, and the 8B ran on sm103-v12 in candidate C's own row).

    What the flip measured rather than assumed, and three numbers it refused to restate. (a) No introspection pin for the shipped default existed anywhere, and the near-misses are the finding: test_vlm_analyzer.py:639 compares the degraded label against get_settings().vlm_model_id — self-referential, green on any default — and the 4B literal sits in fixtures in two unit and one integration test, green on a stale default too. TestShippedServingIdentity (3 pins, 2 red pre-flip) derives each spelling from the artifact declaring it and asserts agreement then names the model, because the agreement check alone passed green on the old tree with all five spellings consistently saying 4B — naming is load-bearing, agreement is not. (b) Three prose sites carried 4B numbers as if measured and none was. The compose KV line ("~73KB per token per slot, 2x16K slots ~2.4GB") and this report's own 4608 MiB (~144KB/token) describe the same 32768/2 pool and disagree by ~2× — I first wrote "same pool, different units," which papers over a real conflict; it now names the disagreement as UNRESOLVED with llama-server's own startup KV line as the authority and the handout asked to capture it. The residency comment's "wake is seconds for a 4B" had no measurement anywhere in the repo, so it states the pinned byte counts and the ratio (5,027,784,800+752,289,728 vs 2,497,281,664+453,974,304 = 2.0×, corrected from a 1.7× I wrote before dividing) and sends the actual to the handout against AI_VLM_WAKE_TIMEOUT_SECONDS=90.0. The healthcheck's 120 s keeps its value because it mirrors the image's own --start-period=120s (ai/vlm/Dockerfile:133, verified) but lost its 4B-vs-30B anecdote as the reason, and "record the 8B's actual load time against this window" went into the handout instead of my guessing a bigger number. (c) Two anchor citations were stale before this slice touched anything — the handout's profiles:[vlm] (docker-compose.prod.yml:221,:227-228) (the block is at :241 and was at :241 in 2af6d552 too) and the test file's .env.example:576/:580-583 for a CUDA var now at :601. Item 25's warning about file:line anchors going stale within one slice is now demonstrated twice more; the sites inside my own text cite variable names instead, and the rest is reported here rather than silently re-anchored file-wide.

    Gates (executed, this tree): unit -n auto → 1 failed, 30577 passed, 123 skipped, 8 xfailed — sole failure the sanctioned test_skips_when_skip_build, arithmetic exact at 30574 at head + 3 new pins, and reproduced twice; between the two runs my only edit was inside a # comment and compose is read by no test except through yaml.safe_load (test_ai_vlm_compose_service.py:32), so the identity validly names the tree. Compose suite 39 passed; precheck suite 48 passed untouched by the flip — its fixtures are synthetic and the pair check's regexes (qwen3vl, q4_k_m) already admitted the 8B filenames verbatim, so no new check and no check-id was added, which matters because test_a5500_precheck.py:646-659 pins that exact ordered list. One red did come from my own prose and the test was right: :283 asserts "Qwen3VL" in c.detail — the concatenated spelling an operator types in a filename — and I had flattened the old string's deliberate two-spelling redundancy; I restored the string rather than relax the pin. PG :5433 and Redis :6380 connect-checked OPEN.

    CLOSE POINTER: this item stays [O] and is the item the owner's runs close. It needs (1) the A5500 handout's rows — 8B S1 peak, the 4B fallback S1 peak, the load time against 120 s, the wake time against 90 s, and llama-server's KV line (M1 assertions 2/3 ride the same run) — (2) the Brev matrix's 24 GB tiers confirming or triggering flip condition (i), and (3) the post-item-19 real-corpus S2/S3 against S2_MAX 5 % / S3_MIN 90 %, which is also where flip condition (iii) gets answered. Every fit figure above is a GB300 indicative reading (F13) and never a bar verdict (F14); this item records a decision and the measurements that will test it, and claims no S#.

39. A5500 RUN READINESS AUDIT: the handout could not execute the run it exists to drive, and the audit's most valuable finding is a bar it never asked for (2026-09-28) [V]. Asked before the owner boots the box, not after: "if I bring the A5500 online, is there documentation or a branch we can point it at?" The branch was always the right answer; the handout was not, and that is the kind of finding that costs an afternoon on a 24 GB machine instead of an hour here. Method: a read-only fan-out (five cold readers + one completeness critic) over the handout, its generator, the spec's bars, the compose and image facts, and fresh-box prerequisites — then every blocking claim re-verified by me in the file before acting on it, because an audit's file:line is a claim too. What it found, all confirmed: grep -ic S4 and -ic p95 were zero in both the handout and its generator, on the one box the spec assigns S4 to (spec :86, :388); S1 was requested as a bare verb with no 20.4 GiB bar, no resident set, no sampler — and VLM_GPU_LAYERS defaults to auto (docker-compose.prod.yml:269), so an over-budget serve spills to CPU RAM, looks healthy, and can post a fake S1 pass; the mandatory P0.3 probe was prescribed as a one-shot "refusal check" when scripts/vlm_probes/enforcement.py is a nonce-const grammar check whose own docstring warns that a wall of refusals must not be read as the verdict — and finding ① is exactly a lone ENFORCED that slipped an intermittently-failing endpoint; there is no image to pull (no image: key, no ghcr presence, no VLM_IMAGE, and deploy.yml never builds ai-vlm) so the box must build, while the shipped CUDA_ARCHITECTURES=89 is not a superset of 86 and nothing in ai/ carries +PTX; and the up the handout prescribed was physically unexecutable — backend carries depends_on: ai-llm: condition: service_healthy (:708-717), ai-llm is unprofiled (:120), and compose config --services under --profile vlm resolves 20 services including ai-llm, so "keep it out of the up set" was prose with no implementation.

    • What was fixed, and the two things deliberately NOT fixed. Fixed in the generator (AMENDMENTS + re-render — the .md is generated, so editing it is editing an artifact): S1's bar/sampler/no-offload trap, a full S4 row with its two cold-start cases, the probe named + invoked + N>=3 + relabeled, the tool-calling probe (spec :379 assigns it here and flip condition (ii) waits on it), the build command with the nothing-to-pull fact and the arch-blind-provenance warning, a weights row for a cold box (both pairs, bytes, sha256s, target dir, finding F's chmod 644), the M1 proof chain from plan :181, the Triton/gateway static-repository row and the Florence clause that had been dropped between spec and handout, a new "Environment and first run" section (the two FAILs are the pre-fix state; --env-file defaults to the template, not the box), and env-templates/a5500.env.template (new file — the repo had only a GB300 one pinning arch 103, and .env.example cannot even render compose: PODMAN_SOCKET :? at :1508, POSTGRES_PASSWORD :? at :69). Not fixed, on purpose: (a) ai-llm was NOT given a profiles: block — compose errors when depends_on names a service in a disabled profile, so it would break every plain up, which is an owner call about prod compose, not a side effect to slip into a bring-up slice; the handout now carries the repo's own proven answer instead, the GB300 bootstrap's two-phase up -d --no-deps backend frontend (scripts/bootstrap-gb300.sh:270-277, commented "never plain up — GPU deps"), verified against config --services. (b) scripts/platform-healthcheck.py probes only 127.0.0.1:8091 — the retired service's /health, /v1/models, /slots (:172, :178, :189, :440) — and has no ai-vlm/8098 branch, so on a vlm-only box it can fault the service that correctly isn't running and cannot see the one that is. That is a real gap and is recorded with a check-/props-directly workaround rather than fixed: rewriting a shared probe mid-run moves the ground under the run being measured.

    • Three corrections to my own recent work, found by looking. (a) the weights are NOT what the A5500 lacks (written into the handout yesterday) is true only of the GB300's broker share $AGENT_GPU_DIR/models/vlm, which exists solely behind agent-gpu on the dev box — false of a cold A5500, which has no weights at all; the row now says so and carries the pins. (b) The 4B fallback pair had no sha256 anywhere in the repo even though this run is required to serve it: Qwen3VL-4B-Instruct-Q4_K_M.gguf 2,497,281,664 B sha256 66358cb18bb6b3b1b6675aa412c7a88ef01d228f481184d13668e5201c730a0a + mmproj-Qwen3VL-4B-Instruct-Q8_0.gguf 453,974,304 B sha256 30ba2c7dd3127a4561b6cba9d13d0f711c91bdb38742e2f56d73c8cb596bd06d, measured on the share today. (c) My own "~2x" KV conflict from 54141d9c picked a side of an unstated basis. The report says "4608 MiB / 16384 cells" without saying whether that is one slot's KV or the whole pool expressed per 16K; read per-slot it is ~4× the old compose prose, read per-pool ~2×. Both the compose comment and the handout row now state the spread and name the ambiguity, and assert only what the report's own header supports — that 4B and 8B share the KV row, so the cost does not move with the fallback.

    • A pin that was green on the broken tree, caught by my own test. Nine pins were written first for the render (the render is what the operator reads), and eight went red — but the build pin passed pre-fix, and the reason matters: --build-arg CUDA_ARCHITECTURES=86 already appeared inside _check_vlm_image's PASS detail, so a substring check was green while the handout still printed no actual invocation. That is the same self-referential-pin pattern this file flagged at item 35(a), reproduced in my own work the same day; the pin was tightened to require the real command and the nothing-to-pull fact rather than relaxed. The handout is also the second place this repo has been bitten by prettier pairing mid-word underscores — CUDA_VISIBLE_DEVICES=${GPU_*} ships as CUDA*VISIBLE_DEVICES=${GPU*\*} and Q4_K_M as Q4*K_M in the committed file, which is load-bearing here because an operator types what the page says. Proven empirically with a scratch file (corrupted without the ignore entry, intact with it), then both handouts were added to .prettierignore following the archive/ precedent already documented there.

    • Stale anchors, found not inherited (item 25's warning demonstrated a third time): the handout's spec :482-500 for the no-legacy-LLM rule (that range is M3 and Phase 4; the row is at :523, plus :412), and .env.example/compose line anchors off by 25–30 because .env.example grew ~25 lines in this slice-set. Sites inside my own new text cite variable and service names instead of line numbers, and the ones kept (compose:240, :253, :265-266, :708-717, :1508, :69, Dockerfile:133, bootstrap-gb300.sh:270-277) were re-read today.

    • Gates (executed, this tree): precheck suite 57 passed (48 at head + 9 new); TDD order real — 8 red, then green, then one pin tightened after it was found green-on-broken. Render verified after every edit and the eight load-bearing operator strings checked in the committed file (20.4 GiB, nvidia-smi --query-gpu=memory.used, --no-deps backend frontend, podman build --build-arg CUDA_ARCHITECTURES=86, enforcement.py --url, N>=3, chmod 644, uv run python, clean CUDA_VISIBLE_DEVICES=${GPU_*}) with zero corruption patterns remaining. gen-ai-contract --check current; contracts 646 and integration 5 passed were established for this branch earlier today and no code path they cover moved here (docker-compose.yml comment prose and precheck/handout text only).

    CLOSE POINTER: this item is [V] — closed as an audit — and it does NOT close M1 or item 35; it is what makes the run that closes them executable. Still owner-owned: the run itself, and the decision on whether ai-llm should ever be profile-gated in prod compose. Still open in the repo, reported not fixed: platform-healthcheck has no vlm branch, the spec's S2/S3 rows keep their [?] (an S# edit is the owner's), and Phase 2's plan :117 still points at the A5500 checklist as the source of S1/S4 — a pointer that was incomplete until today and is now honest.

40. THE OPERATOR HANDOFF: what the run needed was an ORDER, not more facts, and writing it caught two hazards of my own making (2026-09-28) [V]. The owner's instruction was "fix whatever you can before I bring it online … push an updated version of the branch and a handoff document we can just give the agent operating on that machine." Item 36 had fixed what the checklist says; this slice adds the thing it never had, which is the sequence a cold box walks — because a document organized by spec row is not a document an operator can start from. Three commits: 6c98c0fa (the executable-shape fixes and their nine pins), 38eb8716 (item 36's own record plus the Brev 4B pins), aea3a40a (docs/superpowers/plans/2026-09-28-a5500-operator-handoff.md).

    • The handoff is hand-written on purpose, and says so. The A5500 checklist is generated and stays the authority on what each row means; the handoff deliberately does not restate the four weight sha256s or the S1 arithmetic — it points at the sections that carry them, because a second copy of a number is a second way to be wrong. What it adds is the parts no spec-row layout produces: fetch order (weights BEFORE the precheck, since nothing in the repo can tell you they are missing), the --env-file .env distinction, the build-because-nothing-to-pull step, the two-phase --no-deps up, the measurement order (8B → probes at N≥3 → S1 with the real resident set → S4 with both cold starts → the 4B fallback row → M1's chain), a paste-back contract (verbatim numbers, blocked rows with their output, aggregates only per D10), and the stop list — bars change by owner ruling, the M2 pick reopens by its flip conditions and not by an operator, and the two recorded gaps get worked around, not fixed mid-run.

    • Two hazards found while verifying my own new document — both mine, both the class this ledger already warns about. (a) A stale anchor in a document about not having stale anchors: the handoff first pinned head 38eb8716, which is its own parent — the file did not exist there, so an operator who obeyed the pin exactly would have arrived and not found the document they were sent for. Found by going to check my own claim; the pin is now aea3a40a (the commit that adds the file) with the reason spelled out in the text. (b) An invalid formatter test, caught by the hook rather than by me. I tested whether prettier would corrupt the handoff's mid-word underscores by running it on a /tmp copy — which resolves config from the file's own location, so it used prettier's defaults instead of the repo's and reported "unchanged." The real hook, run from the repo root, modified the file in ten places. The damage is worse than the underscore class item 36 records: prettier also dedents a wrapped inline-code continuation out of its bullet, which mangles a command line an operator copies verbatim. Fix: the handoff joins the two checklists in .prettierignore, and the durable rule is that a formatter test must run inside the tree, never on a copy. Also re-verified the same way: the four digests now have a pin requiring all FOUR (not just the two weights — the mmproj is where the F16 trap lives) with a len(…) == 4 guard so the membership test cannot pass vacuously, and detect-secrets was satisfied only once the digest sat at a nesting depth where the pragma fits inside 100 columns, because ruff-format's wrap orphans a trailing pragma and the scanner then rejects it (both forms checked against the real hook).

    • Gates, from their own output. Precheck suite 57 passed (re-run after the pin restructure, not assumed). Full unit tier on the pushed head: 1 failed, 30586 passed, 123 skipped, 8 xfailed with the only FAILED line being the sanctioned test_skips_when_skip_build — and a dated correction to my own report: I quoted "30662 passed, 53 skipped" once in the same turn from memory before reading the log; the log line above is the figure, and the misquote is the "declare only from the command's own output" rule caught in the act, in a session whose whole subject is claims that outran their evidence. Two facts the handoff asserts were checked at the file rather than inherited: build_gen2 has no CLI (no argparse/__main__ in eval_store.py — it is a function, so the handoff says "the shipped build_gen2(…) driver" and never invents a --generation flag, which is exactly the invented-script failure item 29 records), and data/synthetic carries 413 label sets. Also newly measured for the record: gating the hooks with --files rewrites .secrets.baseline scoped to those files — 138,744 lines deleted in the working tree, restored and never staged — so any future run that gates a subset must expect and undo that.

    CLOSE POINTER: [V] as an artifact; it closes no milestone. It is what makes the A5500 run startable by someone other than me. Still owner-owned: the run itself (which closes M1's assertions 2/3 and produces S1/S4 — item 35's close), whether ai-llm is ever profile-gated in prod compose, S2_MAX/S3_MIN's [?] rows, Brev spend, and every PR/merge. The media agent's synthetic corpus is the input that finally makes S2/S3 answerable, and this handoff tells the operator to record its generation beside their numbers rather than assume one.

41. A5500 BOX PREP ON THE REAL HARDWARE: weights, images and one fix the run needed, and a re-ID export that passes its own validation with a mostly random backbone (2026-09-28) [V]. First slice executed on the A5500 itself, driven from item 37's handoff at head 6fa7942e. The box is not the cold, single-card machine the handoff was written for, and the differences are recorded here so the S1/S4 rows that follow can be read against them.

    • The machine, as measured. nvidia-smi: NVIDIA RTX A5500, 8.6, 24564 MiB at index 0 plus an NVIDIA RTX A400, 8.6, 4094 MiB at index 1, driver 610.43.03; nvidia-ctk cdi list exposes both (nvidia.com/gpu=0, =1, =all). D2's "the A400 is retired" is a deployment fact, not a physical one: the card is installed and in the CDI set. Every GPU_* is now 0, so nothing is placed on it, but the S1 sampler must be nvidia-smi -i 0 --query-gpu=memory.used --format=csv -l 1, or each sample prints both cards. The A5500 also carries the desktop compositor (kwin_wayland, 95 MiB used at idle), and that baseline is part of every S1 reading on this box. Fedora 44, SELinux enforcing, rootless podman, docker compose 5.3.1 provider.
    • Env: patched, not regenerated. The box already had a generated .env (2026-09-14, real credentials matching existing volumes), so the template's deltas were applied onto it rather than re-running setup.py. Applied: all GPU_*=0, CUDA_ARCHITECTURES=86, the rev 7 VLM_* identity, AI_MODELS_PATH=/export/models, and BACKEND_MODEL_PRELOAD=true (see the fix below). Not applied: TMPDIR. Nothing in docker-compose.prod.yml reads it, this .env never set it, and adding it arms the four-test write_runtime_env trap the precheck itself warns about. a5500_precheck.py --env-file .env then printed no FAILs (WARNs: the A400 in the CDI set, ai-llm unprofiled, no ghcr ai-vlm, stale pycache that was cleared before gating).
    • Weights: all eleven files, each checked against a repo pin. AI_MODELS_PATH=/export/models is a root-owned symlink to /home/msvoboda/models (the only large filesystem). vlm/: all four GGUFs, sha256sum -c OK against the checklist's four pins, byte counts exact, and mode 644 on arrival (hf download into a local dir; finding F did not reproduce this way, but it stays a check, not an assumption). model-zoo/: yolo26m.pt OK against ai/download_models.sh's pin; OSNet MSMT17 OK against models.yml (stored under the long name with a relative short-name symlink, which the loader's path guard requires); the face pair OK against models.yml's two pins; the tiktoken cl100k_base cache OK against tiktoken's own expected_hash. The face pair's source is not in the repo: insightface release v0.7 buffalo_l.zip (det_10g.onnx renamed, w600k_r50.onnx). The pins are what make that URL trustworthy, and both matched. scripts/download-model-zoo.py cannot be used for this: it writes to a hardcoded /export/ai_models and fetches ImageNet OSNet weights under the MSMT17 short name, which would fail the pin. The fetch used the sources ai/download_models.sh and setup_lib/model_downloader.py already name.
    • Images: built here, and the driver trap checked, not assumed. ai-vlm:sm86 digest sha256:5f5c2d71dbdb0ed6da3e302c7e0441e7594d40bee4dbe15490d7be8461b71a41, llama-server version: 7972 (e06088da0), and --list-devices inside the container: CUDA0: NVIDIA RTX A5500 (24102 MiB, 23749 MiB free), compute capability 8.6. That is the compute_cap/build pair on one line; /props build_info follows at serve time. libcuda.so.1 resolves to the host's /usr/lib64 (CDI). The image's cuda-13.3/compat (610.43.02) is not on the loader path, so the forward-compat reject that silently dropped the old ai-llm image to CPU on this same 610 host does not fire for ai-vlm. ai-gateway, backend and frontend were rebuilt --no-cache: the prior images were 7 months and 2 weeks old and predated rev 6 residency and the 1.6 frontend.
    • FIX (this commit): the prod container could never load the specialists. (a) Settings.backend_model_preload gates main.py's boot sweep and defaults False. setup.py writes BACKEND_MODEL_PRELOAD into .env, but the backend has no env_file: and no compose file passed it, so on every compose box the face and re-ID legs answered "unavailable" with both hash-pinned weights on disk. Item 32 fixed the sweep and the inclusive 24 GB threshold, not the wire into the container. (b) The prod backend image had no onnxruntime at all: it is in no base dependency (walked from uv.lock), only the face/alpr extras, and the builder's uv sync took no --extra. The fix is BACKEND_MODEL_PRELOAD=${BACKEND_MODEL_PRELOAD:-false} on the backend (default = the Settings default, so a box that never set it boots as before), the var declared in .env.example, and --extra face on the builder sync (onnxruntime 1.30.0 ships cp314 manylinux_2_28 wheels for x86_64 and aarch64, so the GB300 build is unaffected). Four pins went red first for the right reason (TestSpecialistResidencyReachesTheBackend x3, test_prod_dependencies_carry_the_face_extra), then green. Runtime proof in the rebuilt image: onnxruntime 1.30.0 imports; the face detector and recognizer load through face_recognizer_loader (CPUExecutionProvider, 512-d embedding, L2 norm 1.0000); OSNet loads through osnet_loader with 2 missing keys (the classifier only). Owner ruling 2026-09-28: fix both, then measure.
    • A correction to my own first read, before it reached a number: the backend image's torch is 2.14.0+cpu, so the backend's OSNet is a CPU resident. The preload fix is M1's specialist half, not an S1 term. S1's specialist VRAM on this box is the gateway's yolo26 + reid only.
    • FINDING, not fixed: the Triton reid export is a mostly random network that passes its own validation. ai/gateway/export/export_reid.py hand-writes plain OSNet (conv2a..conv2d blocks, a BatchNorm stem plus a separate conv1_IN), while the MSMT17 checkpoint is OSNet-AIN (conv2.N.layers.* streams, an instance-norm stem, separate pool2/pool3). Keys matched: 118 of the model's 577 (classifier, fc, conv5 and some 1x1 layers); the other 459 stay at random init. It passes because load_state_dict(strict=False) only warns, unexpected keys are logged at DEBUG, and the ONNX is "validated" against the same under-loaded PyTorch model (cosine 1.000 at batch 1/2/4/8). It is the same self-referential-check pattern as item 35(a). Blast radius, as traced: the vlm verdict path's person_reid leg uses the backend's torchreid osnet_loader (above, correct), and no vlm_* module references enrichment_client, the Triton reid model's only caller (legacy enrichment). The broken file changes no vlm verdict. It stays resident because the vlm residency set names it, and its graph and weight sizes are identical to a correct export, so S1 is unaffected. It was exported to triton/reid/1/ for exactly that footprint and must not be read as a working re-ID model. Fixing it is a re-ID change and outside this run's scope (item 37); left to the owner.
    • Also noted, not touched: the plate leg's fast-alpr (alpr extra) is still absent from the prod image; docker-compose.yml/ghcr.yml do not pass BACKEND_MODEL_PRELOAD (ghcr cannot serve vlm mode at all).
    • Gates (executed, this tree): backend/tests/unit/core plus every unit test reading .env.example, prod compose or backend/Dockerfile, plus the precheck suite: 4129 passed, 0 failed. Stale __pycache__ was cleared before the run (the precheck's deletion-guard trap).

    CLOSE POINTER: [V] as prep; it closes no milestone. S1, S4, the P0.3/tool-call probes and M1's chain are the next rows and are not claimed here. Owner-owned: the export_reid.py fix (and whether to guard strict=False exports generally), the alpr extra, and whether the other compose files get the preload wire.

42. A5500 RUN, 8B PRIMARY: S1 and S4 read PASS on this corpus, the probes hold at N>=3 on two server builds, and M1's chain ran end to end - after 16 fixes the chain itself surfaced (2026-09-28) [V]. Box, env and weights are item 38. The serving image is ai-vlm:sm86 (llama.cpp b7972-e06088da0), rebuilt once in this row so that the KV cache fix below applies; digests sha256:5f5c2d71… (f16 KV) and then sha256:d165a409… (q8_0 KV). Every reading below is from the q8_0 image unless it says otherwise.

    • Identity, on one line as the handout asks: compute_cap=8.6, /props build_info=b7972-e06088da0, model Qwen3VL-8B-Instruct-Q4_K_M + mmproj-…-Q8_0, modalities.vision=True, CTX_SIZE=32768 PARALLEL=2 (16384/slot), offloaded 37/37 layers to GPU (no CPU offload; the 333.84 MiB CPU_Mapped buffer is llama.cpp's token-embedding host copy, not layers). projected to use 7216 MiB. KV line: llama_kv_cache: size = 2448.00 MiB ( 16384 cells, 36 layers, 2/2 seqs), K (q8_0): 1224.00 MiB, V (q8_0): 1224.00 MiB.
    • The KV disagreement (items 35/36) is settled by that line and its predecessor. The first serve logged size = 4608.00 MiB … K (f16), V (f16): 4608 MiB is the WHOLE 2x16384 pool at f16 (~144 KB/token), which is what the bake-off recorded, and the older "~73 KB/token, ~2.4 GB" prose was the q8_0 figure all along. It was f16 because ai/vlm/Dockerfile never passed CACHE_TYPE_K/V to llama-server although compose set q8_0 - fixed in 58163f23f (with a pin that fails if compose ever sets an ai-vlm var the image never reads). Resident set at idle went 11604 -> 9376 MiB.
    • S1 [V, PASS on this corpus]: peak 9606 MiB (9.38 GiB) vs the 20,890 MiB bar, headroom ~11.3 GB. Sampler nvidia-smi -i 0 --query-gpu=timestamp,memory.used -lms 250 (703 samples) across a full-store replay plus two concurrent heaviest-batch replays (both slots busy), resident set ai-gateway (yolo26 + reid, tritonserver 676 MiB) + ai-vlm (llama-server peak 8822 MiB) + backend (0 MiB: its torch is +cpu, item 38) + the desktop compositor 17-21 MiB. Caveat, stated not smoothed: the heaviest batch this corpus can produce is 7443 tokens (prowling, 4 images; n_tokens from llama-server's own log), not the ~12.2K worst case - the corpus's media items carry no detection rows. The KV pool is allocated at load, so a longer prompt fills it rather than growing it; the unmeasured part is compute-buffer growth.
    • S4 [V, PASS on this corpus]: 21 measured requests, nearest-rank p95 21.7 s, max 22.6 s, bar 30 s. Warm sequential (13 items): median 7592 ms, max 9247 ms (item 1 includes the one-time client probe, 4419 ms). Both slots busy on the heaviest batch: 17.5-22.6 s per item including a per-process probe (4.7-14.5 s under contention; in the product the probe runs once per backend process). Cold restart: page cache dropped (Cached 3.68 GB after, below the pair's 5.78 GB), podman restart -> /health 200 in 12.5 s against the 120 s start_period (10 s of that is llama-server ignoring SIGTERM until SIGKILL - a small finding), first request 12.8 s. Wake: after 300 s idle is_sleeping=true and llama-server fell 8822 -> 290 MiB (GPU0 1074 MiB); first request 13.1 s, its probe 6254 ms vs 4.4-4.7 s warm, so the wake itself is ~1.5-2 s against the client's 90 s timeout. Replay report run_id e15163de5da3457aa34b047c8807c52a: S5 unparseable 0, refusals 0, unavailable 0 of 13; verdict mix confirmed 10 / uncertain 3.
    • P0.3 probes, N>=3 on both server builds: enforcement.py 5/5 ENFORCED ("nonce const echoed") on the f16 image and again 5/5 on the q8_0 image; tool_calls.py --image 3/3 SUPPORTED with required_arg_honoured: true on each. Flip condition (ii)'s tool-calling half is answered for the 8B on this box.
    • M1's chain (assertion 2), link by link, synthetic Cosmos stills only (D10), camera m1_synthetic_p02 created by the watcher in the owner's live DB (events 613-616 are this row's): still -> watcher [V after f88797b4c] -> YOLO26 person 0.89-0.96 [V after 0fcb173df] -> batch -> VLM verdict (7.6-10 s) -> event + event_verifications row [V; provenance correct after 881a6e9d0] -> badge [V at the API: GET /api/events/614 carries the verification] -> notification decision: NOT WIRED - spec §6's null-safe rule exists as notification_filter.should_notify and has no production caller; the backend makes no notification decision at event creation, and desktop/push notify from the browser keyed on a non-null riskLevel. Recorded as a blocked link, not fixed (owner's). Assertion 3 (wake through sleep on the product path) is the next row.
    • What the chain exposed, each fixed red-first and pinned, in the order found (55358ea73…7d9509681, all on this branch): the prod backend could never load its specialists (preload wire, no onnxruntime; 55358ea73); YOLO26 exported the wrong head under unpinned ultralytics 8.4.164 (nms=False + a shape guard; 0fcb173df); the gateway app died at import on Python 3.12 from py314-formatted except A, B: (43 restarts; parenthesized + a ruff py312 pin; d6204d202); the Triton re-ID export was plain OSNet, not OSNet-AIN (118/577 keys, cosine 0.47 -> 1.000000; 728890874); KV quantization never reached llama-server (58163f23f); the retired ai-llm started with every up (now profiles: [legacy], backend dep required: false; 58163f23f), with the backend's health monitor/orchestrator (1337afeb4, b085a03fe, e193f1a6f) and setup.py deploy (078f679d4) also stopped from starting it; the in-client probe budget (400) was below the 8B's 427-429-token probe object, failing every verdict closed (7b2918580, now _ASSESS_MAX_TOKENS + 64 with a pin); SELinux denied the backend's inotify WATCH on the usr_t camera root while the watcher logged success (:z on the mount, f88797b4c; runtime self-check with polling fallback + watch_mode on /api/system/pipeline + a precheck row, ef3ada95e, e9a52afbf, 28779ba94); verification provenance was model-written (the camera id landed as engine and model_id; now stamped from /props, 881a6e9d0); the VLM misread bare [x, y, w, h] boxes as corners, then (convention stated) could not place pixel boxes without the frame size (11d777409), then read three rows from three stills as three boxes on the ONE attached frame and called the detector wrong - rows now name their attached frame (4693ecb63, optional frame_detection_ids on the request, contract regenerated 02e78d83f). With that, event 616 (P03, window_peering) was judged on content ("dark hoodie with the hood up, covering their face with both hands") and no longer on box arithmetic; its uncertain / risk 10 is a judgement question the detections+images eval set (next row) exists to measure.
    • A hazard of my own, found and bounded: running backend/tests/unit/test_deploy_phases.py outside the sandbox overwrote the operator's real ~/.config/containers/storage.conf (mtime 12:23:58) - the stop-phase tests do not isolate HOME. Podman's effective store is unchanged (graphRoot default, 1740 images, 7 containers, February images present) and the written content equals the rootless defaults the file was generated with. A real test-isolation bug, not fixed here; those suites now run sandboxed only.

    CLOSE POINTER: [V] for S1 and S4 on this corpus and for M1 assertion 2's mechanics; it closes neither M1 (assertion 3 and the notification link are open) nor item 35 (the 4B fallback row, the real-corpus S2/S3 and flip condition (iii) are open). Owner-owned: the notification wiring, the storage.conf test isolation, the frontend toolchain drift on this box (typescript-check/eslint fail project-wide on pre-existing errors; one generated-file commit skipped them with the evidence), and whether S1/S4 need a 12.2K-token batch before they count.

43. A5500 RUN, CONTINUED: M1's wake-through-sleep holds; a detections+images eval set moved the 8B's verdicts from box arithmetic to content; S5 and the prompt fit were broken at the 8B's real scale and are fixed; S1 holds at the true slot ceiling; the 4B fallback has its row and fails S5 (2026-09-28) [V]. Same box, image and identity as item 39 (ai-vlm:sm86, b7972-e06088da0, q8_0 KV). Head at the last reading d7b3fd3c6. Media and stores off-repo (D10); every number below is an aggregate.

    • M1 assertion 3 (wake through sleep, product path) [V]. VLM asleep (/props is_sleeping=true, GPU0 1246 MiB); three synthetic Cosmos stills (P03_30s) copied into m1_synthetic_p02 -> watcher -> YOLO26 person 0.946/0.955 -> batch -> event 617 + verification row (llama.cpp@b7972-e06088da0 / Qwen3VL-8B-Instruct-Q4_K_M, stamped), verdict 5367 ms; llama-server logged handle_sleep: server is exiting sleeping state. The mechanics hold. The CONTENT did not: uncertain, risk 0, "the bounding boxes are too small" - for a 419x513 box in a 1280x704 frame, with the pixel convention stated, the frame size named and the row linked to its frame (item 39's three fixes all deployed). That verdict is what led to the box fix below. After it, the same three stills on the rebuilt backend (d7b3fd3c6): event 618 confirmed, risk 75/high, "a person ... wearing a hoodie and covering their face with their hands" at night, 7840 ms, badge at GET /api/events/618. Notification decision: still NOT WIRED (item 39) - M1 stays open on that link alone.
    • The detections+images eval set. Built on the box (outside the repo): 38 items from the committed corpus's labels (18 benign incl. two empty-frame controls, 20 incident), real YOLO26 detections via the backend's own DetectorClient on the corpus stills (1280x704, ~880 vision tokens each), 11 items with two stills. It is the first set where the media-bearing items also carry detection rows, so it exercises the box path the 13-item gen-2 set never did (item 39's caveat). Five arms, same items, same 8B:

    arm	run_id	confirmed / uncertain / rejected / failed	S2 fp	S3 hit	S5 unparseable
    before f88797b4c	6db550f5	4 / 31 / 1 / 2	1/18	5/20	2
    after item 39 4b661c86b	a4e42603	9 / 21 / 5 / 3	0/18	6/20	3
    native boxes, 700 (experiment)	d7d1e7fb	33 / 2 / 2 / 1	0/18	13/20	1
    native boxes, 1024 (experiment)	2ea4b96f	34 / 2 / 2 / 0	0/18	10/20	0
    landed 2fd5c54bc	094847b1	33 / 2 / 3 / 0	0/18 [0, 0.176]	10/20 [0.30, 0.70]	0

    The landed arm's p95 is 7.7 s. The remaining rejections are on content (a cat labelled dog, a light fixture labelled frisbee, a car labelled truck). S3 fails its 90% bar in every arm, and moves ~3/20 between runs that differ only in a budget the non-truncated replies never touched, so single-run S3 differences under ~3/20 are noise here. S3 is score-vs-expected-floor, which the box fix does not address; the bar is the owner's.

    • FIX 2fd5c54bc: boxes in Qwen3-VL's own grounding format. The Qwen3-VL cookbook's bbox_2d is [x1, y1, x2, y2] on a 0-1000 scale of the frame; read that way, event 617's [369, 183, 419, 513] is a sliver, which is exactly what the model said. The rendered rows now carry bbox_2d scaled by the row's linked frame (or the one size every attached frame shares), clamped; a row with no readable frame size keeps pixels and the pixel sentence. Snapshot rows keep [x, y, w, h]. Owner ruling 2026-09-28.
    • FIX 2fd5c54bc: S5 was failing for the 8B on this set. At _ASSESS_MAX_TOKENS=700 the 8B's verdicts on two-image items were cut off (2 in the before arm, 3 after); the harness counts a truncated reply as unparseable - S5's own quantity - and its bar is 0. The item 39 replay passed only because its replies were shorter. The longest 8B verdict, by llama-server's own eval count, is 852 tokens; the budget is 1024 (1.2x, pinned against 852) and the probe budget follows at +64. Owner ruling 2026-09-28.
    • FIX d7b3fd3c6: the prompt fit did not match the served slot. Taking S1 at a genuinely full slot, the client's own fit sent a batch llama-server refused: request (22293 tokens) exceeds the available context size (16384 tokens). (a) Images: the fit reserves 1280 tokens per still, but uncapped Qwen3-VL spends ~1 token per 32x32 px - four 1.9-2.4 MP stills were 8,509 prompt tokens (usage), not 5,120. ai-vlm now sets LLAMA_ARG_IMAGE_MAX_TOKENS=1280 (read by llama-server; --help at b7972), pinned to the client constant; the same four stills are now 5,003. Env-wired, so the measured image is not rebuilt. (b) Text: the same fitted prompt was 10,237 tokens by the repo's counter and 13,785 by the engine's /tokenize (1.35x; Qwen splits every digit and rows are mostly digits). The fit now budgets 1.5 served tokens per counted token (pinned at >= 1.1x the measured gap), deterministically, so the stored llm_prompt is still the prompt sent. (c) The refusal was a VlmTransportError: a breaker failure, then a §6 retry of the same bytes for a second - five such batches open ai-vlm for every camera. It is now VlmContextOverflowError, raised once, counted as vlm_context_overflow, never fed to the breaker, still verification_failed. Owner ruling 2026-09-28. Also 9129e1f32: the contract round-trip leg had been red since 881a6e9d0 (it compared the model's provenance with the client's stamp) - I had run only the unit suites then; it now pins the stamp.
    • S1 at the true ceiling [V, PASS] - item 39's open "12.2K" question, answered. The product's real worst case is a full slot (prompt up to 16,384 - 1,024 output), not the spec's ~12.2K. Both slots at once, four 1.9-2.4 MP stills, resident set as item 39: 8B uncapped (pre-d7b3fd3c6), 14,936-token prompts: peak 9,826 MiB (9.60 GiB); 8B with the landed fit and cap, 400 rows trimmed by the client to 14,130-token prompts, 6/6 served, 0 overflows: peak 9,722 MiB (9.49 GiB). Bar 20.4 GiB; offload none (37/37). The vision encoder's buffer grows with image size, so the uncapped reading is the conservative one.
    • S4 at the ceiling. Pre-cap, two concurrent full slots ran attempts past the 25 s AI_VLM_READ_TIMEOUT: a transport error, then a faster retry on the server's cached prompt, 35-47 s end to end. With the cap: per-attempt 6.6-22.3 s excluding the per-process probe (12.2-30.5 s including it; the product probes once per backend process), no retries. Item 39's corpus S4 (p95 21.7 s) stands; the ceiling is recorded, not part of that p95.
    • Load times from a dropped page cache (drop_caches while the OTHER pair was being served, so the pair about to load was mapped by no process and was evicted; the 3.2-3.6 GB Cached left is shmem plus pages mapped by running services, so it is not the evidence), container start -> /health 200, +-1 s (the start stamp is whole seconds): 8B 2.2 s, 4B 2.6 s, against the 120 s start_period. A warm-cache recreate of the 8B: 1.5 s. Item 39's 12.5 s restart was ~10 s of llama-server ignoring SIGTERM plus the same ~2.5 s load.
    • 4B FALLBACK ROW [V]. Qwen3VL-4B-Instruct-Q4_K_M + mmproj-...-Q8_0, same image and b7972-e06088da0. projected to use 5125 MiB (8B: 7216); offloaded 37/37 layers to GPU; KV line size = 2448.00 MiB (16384 cells, 36 layers, 2/2 seqs), K (q8_0): 1224.00 MiB, V (q8_0): 1224.00 MiB - identical to the 8B's, as the handout predicted (shared 36-layer geometry: no KV relief). Probes: enforcement 5/5 ENFORCED, tool_calls 3/3 SUPPORTED (required_arg_honoured: true). S1: peak 7,192 MiB (7.02 GiB) on item 39's procedure; 7,228 MiB (7.06 GiB) at the capped ceiling. Load 2.6 s. But the 4B fails S5 on this box: the 13-item gen-2 replay (run 35a4b5ec) returned 8 of 13 VlmTruncatedError at max_tokens=1024 (the 8B: 0 of 13, run e15163de), and at the ceiling 4 of 6 verdicts truncated and one in-client probe hit its 1088 budget before the const (fails closed as ConstrainedDecodingNotEnforced). The 4B's five complete replies were 1,046-1,705 characters (~300-500 tokens) while the failures ran past 1,024 tokens - a split that reads as runaway generation rather than a wordier model, but the truncated bodies are not stored, so that is a hypothesis, not a measurement. For flip condition (i): if the 8B ever failed S1, the fallback has a fitting S1 number, but not a passing S5.
    • SELinux coverage (56c28d2cd..00b344ad7, owner ruling "all compose + setup preflight"). foscam-init mounts the camera root :z (the audit log holds 16 avc: denied { setattr } by chown on /export/foscam itself, 2026-09-11..09-28, hidden by its || true), the ghcr backend :ro,z; the compose pin now covers every tracked compose file; setup_lib/selinux_check.py is the one check both a5500_precheck.py and setup.py deploy use (warn-only preflight after the camera root exists, and a post-deploy read of /api/system/pipeline watch_mode).
    • Found, not fixed (owner's): (a) the backend's container orchestrator never starts on an SELinux-enforcing host - avc: denied { write } by container_t on the rootless podman.sock (user_tmp_t), logged as "Container orchestrator initialization failed ... PermissionError(13)" then "Continuing without orchestrator" on every start today; the usual fix (label=disable on the backend) trades away confinement, so it is a security call. Item 39's orchestrator change was therefore never exercised live on this box. (b) The backend cannot write /app/data/logs/*.log (EACCES with no AVC - ownership, not SELinux). (c) An empty untracked backend/api/helpers/ (a deleted module's leftover) reddened a contract pin locally; removed.

    CLOSE POINTER: [V] for M1 assertion 3's mechanics, S1 at the true slot ceiling, the 4B fallback row (S1, load, KV, probes), and S5 for the 8B on the detections+images set; it closes neither M1 (the notification link is unwired) nor item 35 (S3 below its bar in every arm; the 4B fails S5). Owner-owned: notification wiring; the orchestrator's SELinux socket denial; whether the 4B remains a viable fallback given its S5 row; the S3 bar or the scoring it measures; plus item 39's storage.conf test isolation and frontend toolchain drift.

44. A5500 S4 RE-TAKEN ON THE SHIPPED VERDICT PATH: p95 16.2 s over item 39's 21-request shape, bar 30 s (2026-09-28) [V]. Item 39's S4 predates three changes to the verdict path - the 1024-token budget and native boxes (2fd5c54bc) and the 1280-token image cap (d7b3fd3c6) - and only 24 GB-class hardware can close S4 (F13), so it was re-taken before the box powers off. Code at cedac0a64, runtime-identical to the rewritten remote head 296dde7f6 (the remote's later commits are CI/suppression and main's dependency merges; backend/services, backend/core, ai/, docker-compose.prod.yml and backend/evaluation diff empty). Same image, 8B pair, LLAMA_ARG_IMAGE_MAX_TOKENS=1280 live, resident set as item 39.

    • The 21 requests, same composition as item 39: warm sequential gen-2 replay, 13 items: median 5,982 ms, max 8,835 ms (item 39: 7,592 / 9,247). Both slots busy on the heaviest batch (prowling, 4 stills), 3+3: 13.4-16.2 s per item including a per-process probe (item 39: 17.5-22.6 s; the image cap is the likely reason - prowling's stills are 1.9-2.4 MP, now capped at 1280 tokens each). Cold restart (page cache dropped; podman restart -> /health 200 in 12.9 s, again ~10 s of it llama-server ignoring SIGTERM until SIGKILL): first request 13.3 s. Wake (is_sleeping=true, GPU0 1244 MiB, after 300 s idle): first request 14.5 s. Nearest-rank p95 16.2 s, max 16.2 s. S4 PASS, with more margin than item 39's 21.7 s.
    • S5 on the corpus replay (run d0cab1c8): unparseable 0, refusals 0, unavailable 0 of 13. S1 peak during the sample 9,662 MiB (9.44 GiB).
    • Stated, not smoothed: the verdict mix on these 13 items moved from 10 confirmed / 3 uncertain (item 39, run e15163de) to 6 / 7. These items carry no detection rows, so the box change cannot reach them; the candidates are the image cap (the stock stills are downscaled to 1280 tokens) and run-to-run variance (item 40 measured ~3/20 swings between runs that differed only in an unused budget). One run does not separate the two. The 38-item detections set (item 40), whose stills are 1280x704 (~880 tokens, under the cap), is unaffected by it.

    CLOSE POINTER: [V] for S4 on the shipped verdict path. S1 (item 40, 9.49-9.60 GiB at the true slot ceiling) and S4 are both current for the 8B at this head. Any later change to model, context, image handling or output budget needs this box again; S2/S3/prompt work does not.

45. R8 SLICE S0 — CURRENCY, SHIPPED ALONE: three stale status lines corrected, a gate that keeps them corrected, and R8's landing docs (2026-09-29) [V]. PR #6714, commit 6798ee59, branched off main at 51f635e5. No code changes.

    • The defect. docs/vss-integration/README.md:6, AGENTS.md:6 and 00-context.md:5 (their pre-fix positions; the inserted banners pushed each stale line down) all asserted nothing was implemented, six days after 4bfd6fa4 (2026-09-27, #6681) made the VLM path the shipped default at docker-compose.prod.yml:578. An agent routing from AGENTS.md - the file titled "Start here" - would have concluded the effort was un-started. No CI could see it: agents-md.yml validates presence and references, not content, and scripts/docs-drift-rules.yml carries no vss rule. The gate matches on phrases, not line numbers, precisely so the banner insertion cannot make it drift. [V]
    • The form. Per the in-doc precedent at 06-repo-a-readiness.md:11: the false sentence stays (frozen research prose), with a dated blockquote above it. Order is the rule - a correction the reader meets after the lie corrects nothing. Each banner names the sentence it retires.
    • scripts/check-vss-docs-currency.py + backend/tests/unit/scripts/test_check_vss_docs_currency.py, red-first. uv run pytest ... -p no:randomly -n0 -> 10 passed; the 10 ERRORs are at teardown only (ImportError: libxcb.so.1 via the conftest's cv2, the standing sandbox gap, item 40's class). python3 scripts/check-vss-docs-currency.py -> ok, exit 0. ruff check / ruff format --check / mypy clean. agents_md_validator.py -> dead_links: 0, exit 0. [V]
    • Two defects the gate itself shipped with, caught before commit and now pinned by tests. Both are plausible prose a future author will write, which is what makes them the finding rather than the typo-hunting:
    • It searched the claim's first occurrence and asked "is a banner above it?" A correction that quotes the sentence it retires (The line below ("Nothing is implemented yet.") is stale) makes that first occurrence the banner's own line - so a correctly written doc FAILED. Fixed: occurrences are sought outside banner blocks, and a claim standing only inside a banner is reported as the frozen-prose violation it is.
    • It accepted any dated banner above the line. 00-context.md:3 carries an Errata banner about other claims and satisfied the gate while its status line stood uncorrected - a false pass, the worse failure. Fixed: a banner counts only if it names the claim, matched on the joined block (these docs are wrapped prose; a quoted sentence breaks mid-phrase). And Status is not an accepted lead-in, because the stale README.md line is itself a dated > **Status (2026-09-23): ...** blockquote - it would vouch for itself. Mutation-checked: deleting one banner from a copy of the real tree makes the gate FAIL naming AGENTS.md. A gate that only ever passes is not a gate. [V]
    • My own banners carried the defect class they were fixing, and both were caught pre-commit. I cited ledger :403 for S3's failure - :403 is the p95 sentence; the anchors are :401 (landed arm 10/20) and :221 (F14, S3_MIN = 90%). And I wrote "M1-M4 are still open" when the ledger supports only M1 (close pointer :415: "the notification link is unwired") and M2 (the VLM pick is owner-owned, 12 R10); M3/M4 were my inference, not a reading. Corrected to exactly what the sources say. The lesson generalises: re-verify an anchor the turn before you cite it, including one you wrote yourself earlier the same day. [V]
    • Coverage direction: unchanged, by construction. coverage.run.source = ["backend"] (pyproject.toml:612) cannot see scripts/, and the new test lives under the omitted backend/tests/* (:614). Neither merged floor (84 unit / 37 integration) moves, and no floor was touched. [V]
    • R8's landing docs, per 12-postponed-roadmap.md:10. Its own spec docs/superpowers/specs/2026-09-28-r8-legacy-retirement-design.md (What-goes / What-stays / six slices / five open owner items), the measured scope docs/plans/2026-09-28-r8-legacy-retirement-scope.md, the ordered goal prompt, and R8 marked in the index at :23 plus a banner at §R8 - both recording that the owner reversed the "go-live holds 14 days" trigger rather than meeting it, with the two rulings verbatim. [V]
    • Formatting trap worth carrying. The repo's package.json wants prettier ^3.7.4 and the frontend lock resolves 3.9.9, but the pre-commit hook's real version is its additional_dependencies: prettier@3.2.4 (rev: v3.1.0 is only the hook-repo tag). Running 3.9.9 re-padded all 14 unrelated rows of the doc-12 index because one widened cell changes the whole table's alignment; the 3.9.9-clean state is not the 3.2.4-clean state. Reverted and reformatted under 3.2.4 - net diff on that table is one row. docs/vss-integration/*.md is not in .prettierignore, so the dunder-corruption class does not exempt it: the mitigation is backticking every __identifier__, which held here. [V]
    • Sandbox note. git commit fails here with "Author identity unknown" - no user.* is configured and gh auth status shows logged-out (expected, CLAUDE.md). Commits are made per-invocation with -c user.name/-c user.email matching the history's dominant identity; the mounted repo's .git/config is deliberately left unmodified. [V]

    CLOSE POINTER: [V] for S0 - the currency class is corrected and now gated. It closes no milestone and retires no code; S1 (the hard raise on PIPELINE_MODE=legacy) is the first deletion. CI at write-time is queued-to-running, not green - this row states local evidence only; the Gate result is recorded by whoever reads it.

46. R8 SLICE S1 - THE HARD RAISE AND THE BRANCH DELETION, SHIPPED: PIPELINE_MODE=legacy now raises at boot and every branch site the wide grep enumerated is gone (2026-09-29) [V]. PR #6716, commit c98d36af, branched off main at 51f635e5. Read this row's number with care: the row was written, and prettier 3.2.4-clean, as 42. on a base where the S0 row (#6714) had not yet landed - the formatter renumbers every marker in an ordered list to the sequential next value, so it silently RENUMBERS an appended row, not just realigns it (item 42's row carried the same formatter's trap for table cells). #6714 landed first, so this row lands as 43.; the slice is identified by its heading, PR and commit, never the numeral. Owner rulings verbatim (spec §0): "we do not have to support backwards compatability" and "we should hard raise".

    • The defect the raise closes. The validator at backend/core/config.py ACCEPTED "legacy" and logged a warning; a stale PIPELINE_MODE=legacy in a deployment's .env booted the unsupported pipeline and looked like a normal boot. A warning is not a guard. It now raises for legacy and every unknown value (the never-silently-fallback rule, spec §2:81-84), and an UNSET mode still defaults to vlm - pinned so the raise cannot widen into "missing PIPELINE_MODE crashes every deployment" (the prod compose default is ${PIPELINE_MODE:-vlm}). [V]
    • The raise is written branch-free on purpose, and that is the design, not an omission. The validator never writes if value == "legacy" - it accepts "vlm" or raises, with the retired spelling named only in the message text. That shape is forced by the new guard backend/tests/unit/test_no_legacy_pipeline_branches.py: an AST scan failing any shipped backend/*.py that COMPARES anything against the "legacy" string constant. A validator that special-cased the word would be the one branch the gate exists to prevent. Independent scan at this head: legacy comparisons in shipped code: none. [V]
    • The deletions (the WIDE grep's 13 sites - the narrow grep misses locals that re-derive the mode): mode branches in main.py (the AI-service health monitor list is built by build_ai_service_health_configs, YOLO26 only - on 2026-09-28 the retired pair it used to carry made the monitor probe nemotron, find it down, and attempt to restart the 30B ai-llm onto the same 24 GB GPU ai-vlm needs; the restart failed only because the podman socket was unreachable), api/routes/health_ai_services.py, api/routes/system.py, core/container.py, services/container_orchestrator.py (the retired LLM containers are never registered), services/pipeline_factory.py, services/system_broadcaster.py. Mode-fiction residue renamed: ai_services_config_for_mode -> shipped_ai_services_config (the settings param was unread - ARG001 - and _for_mode described a branch that no longer exists; noqa would have kept the confusion R8 exists to remove), _check_vlm_mode_ai_services_health -> _check_shipped_ai_services_health. [V]
    • The test conversion ran under one stated rule, not search-replace: tests exercising production OUTPUT were rewritten to the shipped ai-vlm shape; tests that directly call surviving nemotron leaf helpers (_check_nemotron_health*) were left untouched - their deletion belongs to S2; mode-parameterized byte-pins of the legacy arm were DELETED, not adapted - their subject was the branch. Mock taxonomy learned the hard way: a plain MagicMock() settings must spell ai_vlm_url (an auto-attr leaks a mock object into the pydantic-validated AIServiceHealthDetail.url), and create_autospec(Settings) mocks must set it too (spec'd mocks raise AttributeError instead of inventing). Fixtures that constructed Settings(pipeline_mode="legacy") now ERROR - the hard raise working on itself - and pin the shipped default instead. Integration legacy_wire narrowed to wire-only (its mode pin hard-raises); the fast-path e2e test kept its coverage via an injected recording analyzer and now pins that the shipped fast path routes through the batch gate and never writes nemotron's is_fast_path column. [V]
    • Evidence. Gate files (test_main.py, test_no_legacy_pipeline_branches.py, test_config_pipeline_mode_hard_raise.py): 38 passed. S1 sweep (the 15 touched files incl. deploy tests): 713 passed. Full backend unit suite: 32,495 passed, 64 failed + 1 error - and the failures were PROVEN pre-existing, not assumed: the identical sweep run on HEAD from a git stash push --include-untracked tree fails the same environmental set (cv2/libxcb-class files S1 never touches, the systemctl-missing deploy phase - item 40's class), and the strict set-diff against the union of two HEAD runs is empty in both directions. The one tempting false positive: four test_nemotron_analyzer_batch25_FINAL_tail-2 span tests appeared in the S1 run and not in one HEAD run - they pass 5/5 standalone and in deterministic pairs, and a second HEAD run reproduced all four (69 fails, 4 tail-2 hits), so they are pytest-randomly order flakes that predate this PR, not S1 regressions. ruff check backend/ / ruff format --check / mypy on the changed sources: clean. The full-suite numbers are LOCAL - CI at write-time is queued, not green; whoever reads the Gate records it. [V]
    • Two real holes enumerated instead of scope-crept, both outside S1's branch-site scope. (a) setup_lib/deploy.py:56 still validates ("vlm", "legacy") and offers the legacy selection - the deploy tool is a separate subsystem (bring-up), outside this PR's AST-gate scope (backend/); after this merge a legacy deploy no longer boots silently, it crash-loops loudly at the backend, which is the ruling's effect arriving anyway. Goes with the slice that owns bring-up. (b) main.py:325 still pre-registers a nemotron circuit breaker (monitoring-UI furniture), and the production-dead _check_nemotron_health* helpers plus Settings.nemotron_url survive - all belong to S2, the nemotron teardown, as does hoisting nemotron_analyzer.py:294-411 to services/constrained_decoding.py BEFORE the rm. [V]

    CLOSE POINTER: [V] for S1 - the raise is live, the shipped code carries no legacy comparison, and the guard keeps it that way. It retires no nemotron code yet (S2), no provider rows (S3), no tables (S4), no frontend panels or docs sweep (S5). Owner items (spec §8 / scope §11) unchanged.

47. R8 SLICE S2b - THE DELETE LANDS: the legacy LLM analyzer and the whole enrichment tier are gone, the survivors are re-homed on ai-vlm, and the test surface is green behind them (2026-09-29) [V]. Commits 602379e2 (the deletion + re-home) and 6266c96d (the test-side fallout, census adjudication). PR stacked on S1's branch. S2a (0ba90d5f) did the EXTRACT first - the constrained-decoding vocabulary already lived in backend/services/constrained_decoding.py with its four shipped importers repointed, which is what made the delete possible without touching the VLM path.

    • What went. nemotron_analyzer.py (5,429 L) + nemotron_streaming, analyzer_facade, prompt_auto_tuner, nemotron_latency_optimizer, skeleton_action_service, pose_analysis_service, enrichment_pipeline, enrichment_client - plus the legacy periphery that died WITH the tier: 19 of the 22 model loaders (reachable only through enrichment_pipeline / model_zoo._LOADER_MAP / a TYPE_CHECKING import in prompts.py), vision_extractor, package_tracking_service, florence_extractor, ai/nemotron/ (build context), ai/start_llm.sh, ai/start_nemotron.sh, and the three quantization-benchmark scripts whose only refs were each other. Spec §2's three survivors stay: face_recognizer_loader, osnet_loader, fast_alpr_loader (+ model_loader_base) - face/plate lookups are DB lookups a VLM cannot do from pixels. ai/ dirs were removed with git rm, never rm -rf.
    • The re-home (owner ruling "Re-home on ai-vlm", spec §8 item 4). summary_generator, prompt_service, audit and performance_collector now read settings.ai_vlm_url; nemotron_url and its kin are DELETED from Settings (kept on purpose: nemotron_context_window - it binds CTX_SIZE - nemotron_max_output_tokens, nemotron_verification_engine, llama_slot_count). ai-llm left every compose, the ai/nemotron build context and the prometheus/alert rows went with it, and the prometheus job rename to ai-vlm-metrics is honest because ai/vlm/Dockerfile:168 carries --metrics in its own CMD.
    • Two deliberate keeps, so a future reader does not "fix" them. (1) The DI registry still registers VLMAnalyzer under the STRING "nemotron_analyzer": pipeline_factory is the only class-choice seam, main.py:763 + core/dependencies.py:95 resolve by that name, and backend/tests/unit/test_r8_s2b_nemotron_deletion.py::TestDiNameIsDeliberate pins it as a decision. The rename is S3's, ruled in-session 2026-09-29 - the retirement of a class and the renaming of a wiring string are different risks and one slice carries one of them. (2) RETIRED_LLM_SERVICES = {"ai-llm","ai-llm-vllm"} stays in container_orchestrator.py: discovery lists stopped containers, and the guard must keep refusing to manage a stale pre-R8 container on a host that still has one. ALLOWED_RESTART_SCRIPTS shrank to {"ai/start_detector.sh"} - a restart allowlist must not stay pointed at a retired engine.
    • P0.3's startup gate did not lose its teeth. S2b deleted test_p03_constrained_verdict.py (1,515 L) and test_p03_verification_producer.py with the analyzer they were built on; TestStartupGateSurvives in the S2b guard file now pins run_constrained_startup_check behaviorally (probe-pass → enforced crossing the registry by the retired name, IGNORED → not_enforced not a crash, disabled → disabled without network, endpoint-down → inconclusive, and the gate ordering BEFORE main.py's swallowing Redis block). The verdict vocabulary keeps exactly one home: constrained_decoding.py, pinned by test_one_home_for_the_vocabulary.
    • Command + result (all re-run on the committed tree, not inherited). Contracts: PYTHONPATH=/tmp/cv2stub uv run pytest -q -p no:randomly backend/tests/contracts → 646 passed, 0 failed (at the deletion's edge it was 8 failed / 638 passed). Unit tier: same invocation on backend/tests/unit → 27,294 passed, 124 skipped, 8 xfailed, 35 failed + 1 error, and the 35+1 are all the pre-existing /tmp/cv2stub InvalidSpecError: Cannot autospec attr 'VideoCapture' class in test_frame_extractor / test_rtsp_test_service / test_stream_manager - files untouched since 53c93d20; this goal prompt's own MINES says "66/96 error at import here (no cv2) - judge by CI". uv run mypy backend/ synthbench/ → Success, 1614 files. ruff check backend/ synthbench/ + ruff format --check → clean. scripts/check-test-collection.py backend frontend ai → 4108 files, all collect >= 1. check-flake-allowlist.py → 0 entries. check-ai-provider-parity.py --expect .github/ai-parity-baseline.json → exit 0. gen-ai-contract.py --check → current. ratchet-check.py → exit 0 (was 85 violations here); suppression-census.py --expect "$(cat .github/suppression-baseline.json)" → exit 0; scripts/test_suppression_census.py + test_ratchet_check.py → 29 passed. prettier --check on every touched md/yaml/json → all match (3.9.9 reproduces the committed shape; the 3.2.4 ordered-list renumbering trap is why the row's own number is stated rather than trusted).
    • The census moved, exactly as the goal prompt warned, and it was adjudicated not edited. unspecced_patch 142 → 88 and pytest_skip_imperative 101 → 99 through ratchet-check.py --update (the sanctioned fall path) + suppression-registry-gen.py, with scripts/test_suppression_census.py's in-file spec mirror updated in the same commit carrying the dated note in the established style. The distinction that mattered: 68 STALE entries licensed mock-patches in files this slice deleted, so they die with their sites ("entries must not outlive what they license") - but the 16 LAUNDER/UNREGISTERED sites in conftest.py and e2e/test_gpu_pipeline.py were not new suppressions: they are the SAME 11 skips line-SHIFTED by this commit's deletions, because the imperative-skip ids are file:lineno. Their written verdicts were carried forward by re-keying HOST_JUSTIFIED (6 keys) and the registry rows (11), and the two batch25 adjudications died with their file. One pre-existing orphan surfaced here and was fixed where found: S1 renamed test_check_ai_services_health_nemotron_down → ..._ai_vlm_down at 734f5e40 and left the registry entry behind (S1's ratchet-check was already exit 1 with those 2 violations - measured in a clean github/main worktree, where main itself is exit 0). No floor was lowered (84 unit / 37 integration, ci.yml:613/:1215), no quarantine widened, nothing hand-edited.
    • Characterization doctrine, the part a junior will want. A pin that reads a deleted file's text has three honest answers and the file says which it got: RETARGET to the surviving shipped text (g4 → florence_client.py:94, the fourth spelling's surviving home, still exactly one literal; g5 → reid_service.py:523 + a tombstone assert that the deleted file stays deleted; N1b → the B5 fixture pair's surviving home test_household.py:738/742, which is what its own escape hatch instructs); become a TOMBSTONE when the defect was deleted rather than fixed and there is no surviving text (V3's enrichment type/class_name precedence split was LOCAL to enrichment_pipeline.py - the test now states the hazard in full and asserts the file's absence; the provider-wire-key half of V3 still pins live in the same class); or read a FROZEN VERBATIM COPY when the pin is an adjudicated evidence record that must not go silent (TestS5ThinkTagStripping, the D1-D6 Tier-A record). The last one is new and is worth the rule it sets: backend/tests/contracts/ai_providers/retired_providers.py is evidence-only, imported by nothing that ships, never collected, and its code was extracted BY LINE RANGE from git show 0ba90d5f:... rather than retyped, so the regex literals are byte-identical to what made the claims true. Deleting the pins would have made the contract tier silently quiet about a defect set the parity golden list still adjudicates; a skip would have been a suppression needing a registry entry AND would assert nothing; git show at test time is un-runnable on CI's shallow checkouts.
    • Holes enumerated, not scope-crept (each owned by a slice, so none can be lost). S3: the gateway florence2/florence_client provider rows and the model_management Triton prose (one provider per slice), the 11 FULL_MODEL_SET Triton models to prune (KEEP yolo26/reid/threat), and the "nemotron_analyzer" rename ruled in above. S4: the dated DROP SQL for the tier's tables. S5: the frontend panels (EnrichmentViewer/Badges/Panel, EventEnrichmentSummary, poseVisualization.ts) and the docs sweep - which now owns README.md:47 and :125 (still narrate Nemotron-3-Nano + the ai-llm container as "the brain of this system") and the two docs that still print the deleted nemotron_api_key (docs/architecture/observability/structured-logging.md:214, docs/architecture/security/network-security.md:379); the root AGENTS.md engine lines were retired in THIS slice because 602379e2 had made its own ai/ tree row false (ai/nemotron/ listed, ai/vlm/ missing) - fixing a fact your own commit broke is not the doc sweep, rewriting narrative prose is, so no model name was asserted anywhere: the ledger's D5 ruling keeps model identity a config choice. Kept-and-DEAD, flagged not deleted (deletion is a slice that must say so): scene_ocr_service.py (its caller tier is gone), trajectory_analyzer.py (orphaned the same way), ai_fallback.py's zero-consumer binding, QUANTIZATION_RECOMMENDATIONS' florence/nemotron rows, and setup_lib/model_downloader's deprecated lists and now-unreachable downloaders. API-surface discipline held: NemotronMetrics / PerformanceUpdate.nemotron / collect_nemotron_metrics keep their names because the frontend consumes them - renaming a public shape is not part of deleting an engine. notification_filter.py:35 should_notify untouched, per the hard rule.
    • Coverage direction (reported, never lowered). Deleting ~30 modules removes covered AND uncovered lines, so the merged unit percentage can move either way and the local sandbox cannot measure it honestly (no cv2, no GPU, and the merged figure is produced by ci.yml's coverage-merge job). Direction as understood and to be confirmed by the CI Coverage Gate on this PR: the shipped surface shrank, the surviving VLM path keeps its pins (646 contracts, 67 guard/hoist/no-legacy tests), and both floors stay exactly where they were. Test Coverage Gate on S1's PR is currently red for an UNRELATED reason - a pytest INTERNALERROR from a xdist worker assertion in test_calibration.py::TestUserCalibrationCreate::test_create_threshold_below_zero_invalid, with the run otherwise reporting 17,741 passed - i.e. a flake in the gate's own pytest invocation, not a coverage shortfall; it is being watched, not worked around.

    CLOSE POINTER: [V] for S2b - the tier is deleted, the survivors run on ai-vlm, and the shipped tree imports none of the dead (an AST scan, not a grep: prose is allowed to name the dead). grep -rn '"nemotron_analyzer"' backend/ --include=*.py over shipped code returns exactly the three DI-seam sites this row declares deliberate; no pipeline_mode == "legacy" comparison exists anywhere outside the S1 AST gate that hunts it and config.py's own raise text; and the SERVICE ai-llm is in no compose (the two remaining ai-llm mentions in compose files are a comment at docker-compose.ghcr.yml:241 saying it was retired, and ai-llm-vllm at docker-compose.prod.yml:278 - which stays, deliberately: it is NEM-5441's vLLM benchmarking harness behind --profile vllm, refused unconditionally by container_orchestrator.RETIRED_LLM_SERVICES, absent from spec §1's what-goes list, and pinned opt-in by test_ai_vlm_compose_service.py::test_the_surviving_engine_stays_opt_in. DONE's "no ai-llm in any compose" is read as "no legacy ai-llm service", which this tree satisfies). It retires no provider rows (S3), no tables (S4), no frontend panels or doc narrative (S5).

48. R8 SLICE S2b, CI'S VERDICT: the delete passed the shipped tree and failed two checks this slice owned - a module the coverage gate could not see, and a secret-scan finding my own test introduced (2026-09-29) [V]. Commit 96b11d2b on PR #6719. This row exists because item 44 followed the house pattern S1's row set - "CI at write-time is queued-to-running, not green; the Gate result is recorded by whoever reads it" - and what the gate came back with was not a pass. Item 44 is NOT edited: its local numbers were true at write time, and the supersession is recorded here instead.

    • Failure 1 - Test Coverage Gate: MISSING TESTS: backend/services/constrained_decoding.py (Required: unit, integration; Tests: None found), with Test Coverage Summary red downstream of it. The module is S2a's hoist and it arrived WITH a 12-pin guard file, green, one filename away. The gate does not look for a test that covers a module: scripts/check-test-coverage-gate.py's find_test_file resolves one BY MODULE NAME (tests/unit/<path>/test_<module>.py, then the integration twin), so test_constrained_decoding_hoist.py is structurally invisible to it. The gate is not wrong - a module-named home is how it and ci.yml find a service's tests - so the fix is the rename, not a REQUIREMENTS exemption. The rename is not merely a rename: S2b deleted test_p03_constrained_verdict.py (1,515 L) with the analyzer it was built on, and while the enforcement VERDICTS survived (TestStartupGateSurvives, the CLI's verdict arms), after S2b nothing in the tree named _is_length_truncated, _TRUNCATED_STOPS or build_probe_schema directly - both were driven only through a fake endpoint. So backend/tests/unit/services/test_constrained_decoding.py gained the behavioral half: TestTruncationIsMeasuredNotGuessed (the closed stop set memberwise in BOTH directions, casing tolerance, literal set identity - the function is a one-way ratchet about EVIDENCE, and the never-truncated arm is what stops a real IGNORED being laundered into INCONCLUSIVE) and TestProbeContractShape (the nonce-const contract, and that the builder does not mutate the caller's schema - both callers hold the SAME imported RISK_ANALYSIS_JSON_SCHEMA, so a mutating extension would ship probe_const inside every production verdict, invisibly on both sides).
    • Failure 2 - Security / Gitleaks Secret Detection, rule jwt-secret, one finding at backend/tests/unit/core/test_config_repr_redaction.py:79: a fixture value 6266c96d introduced, when item 44's retarget of the deleted nemotron_api_key repr pin moved that property onto the live jwt_secret field. Reproduced locally with CI's own binary (gitleaks 8.24.3 - arm64 build, the sandbox is not x86) against the committed .gitleaks.toml, then used as a probe against candidate fixtures: this repo's custom rule captures the field name as the secret and fires at 16+ characters, which is why the sibling pins in the same file (smtp / yolo26 / websocket) pass - their rules want 32+. It also means the config's content-level regexes allowlist and a # pragma: allowlist secret marker (detect-secrets syntax, the other scanner this repo runs) can neither of them reach it. Two fixes, because one is not enough: the shipped fixture is shortened to 14 chars (the property is "a named Settings secret never reaches repr()" and a value's length is irrelevant to it; a stopword wide enough to swallow this rule would have weakened a real scanner to accommodate a fake value), AND .gitleaksignore gains exactly one fingerprint line - gitleaks-action scans the PR range commit-by-commit, so a clean tree does not make the range clean. The fingerprint (commit:file:ruleID:line) was chosen over .gitleaks.toml's commits = precedent at 38b26dd2 (same rule, same shape) precisely because the whole-commit form silences EVERY finding in that commit. No credential exists at that address or ever did; the assertion there is that the value must NOT appear. New root file documented in AGENTS.md's root table beside the other scanner-ignore files.
    • Not mine, characterized and left alone: #6716's Test Coverage Gate red is a pytest INTERNALERROR from an xdist worker assertion in test_calibration.py::TestUserCalibrationCreate::test_create_threshold_below_zero_invalid (run otherwise reports 17,741 passed) - a flake in the gate's own invocation, plus API Types Contract Check / Collection Sanity red in S1's territory. Test Coverage Summary on THIS PR was exit 1 for a reason worth naming: it re-reads the gate job's result and runs no checks of its own, so it is downstream of failure 1 and needed no separate fix.
    • Command + result (this tree, not inherited). PYTHONPATH=/tmp/cv2stub uv run pytest -q -p no:randomly backend/tests/unit/services/test_constrained_decoding.py → 38 passed; neighbors (test_config_repr_redaction, test_config_secretstr, test_vlm_enforcement_probe, test_r8_s2b_nemotron_deletion) → 86 passed. gitleaks 8.24.3 over CI's exact range (--log-opts=--no-merges --first-parent 734f5e40^..HEAD) → "no leaks found", exit 0, and its --log-level=debug trace shows it skipping EXACTLY the one named fingerprint and nothing else - the check that a suppression suppresses only what was ruled. uv run python scripts/check-test-coverage-gate.py --base-branch github/main --strict → exit 0, now resolving backend/services/constrained_decoding.py → backend/tests/unit/services/test_constrained_decoding.py, with the coverage diff honestly skipped (No base coverage available (no coverage-baseline.json at github/main)) - no coverage.json seam was created to manufacture a number CI computes for real. ratchet-check.py → exit 0; suppression-census.py --expect "$(cat .github/suppression-baseline.json)" → exit 0 (baseline unchanged, and worth stating precisely because the census tracks two different things: the new file adds no pytest.skip/xfail AND no mock.patch sites at all - its evidence is source text, AST and real imports - so it cannot add to either the skip total or the unspecced-patch bucket); check-test-collection.py backend frontend ai → 4109 files, all collect >= 1 (4108 + the net new file); mypy backend/ synthbench/ → Success, 1614 files; ruff check + ruff format --check clean on all touched files (ruff's SIM300 ("Yoda condition detected") autofix applied to one assert - confirmed by reverting the assert and re-running, not by reading the diff); prettier 3.2.4 (the version .pre-commit-config.yaml pins, installed separately - the repo's local node_modules prettier is 3.9.9 and reformats table widths differently) clean on AGENTS.md and the ledger.
    • The test-count supersession a future reader needs: item 44's "67 guard/hoist/no-legacy tests" is now 92 - 51 in test_r8_s2b_nemotron_deletion.py, 38 in the module-named test_constrained_decoding.py, 3 in test_no_legacy_pipeline_branches.py (measured by --collect-only, not by hand). Both figures are true of their own tree; the delta is the behavioral half this commit added.
    • A ledger-mechanics defect, recorded because it nearly shipped silently: item 44 went out (67ba9652) WITHOUT its close-pointer correction. The git commit --amend that should have carried it had nothing staged - the edit was still in the worktree - so the amend reported success while amending only the message. Caught by reading git diff afterward, not by the commit's own report. The correction was substantive: the close pointer claimed ai-llm appears in composes only inside retirement comments, which ai-llm-vllm at docker-compose.prod.yml:278 does not satisfy as written. That engine stays, deliberately - NEM-5441's vLLM benchmarking harness behind --profile vllm, refused unconditionally by container_orchestrator.RETIRED_LLM_SERVICES, absent from spec §1's what-goes list, pinned opt-in by test_ai_vlm_compose_service.py::test_the_surviving_engine_stays_opt_in - so DONE's "no ai-llm in any compose" reads as "no legacy ai-llm SERVICE", which this tree satisfies. The correction rode in 96b11d2b. The same amend left a second stale pointer that only surfaced on re-reading the file I had just written: .gitleaksignore's header explained the shortening with 97a2ab59 - the pre-amend orphan, which is unreachable from HEAD and was never pushed, so no reader could resolve it. The right value is 96b11d2b (verified as the commit that changed line 79, via git log -L79,79:...), and it is corrected here rather than silently, because a dangling hash in a file whose whole job is precision is the same defect one layer down.

    CLOSE POINTER: [V] for S2b's CI fallout - both failures this slice caused are fixed at 96b11d2b with local evidence above; the two that are not mine are named rather than worked around. It adds no provider-row retirement (S3), no DROP SQL (S4), no frontend or doc-narrative sweep (S5). Whether the Gate is green on THIS PR is the next reading's to record - as item 44's own pattern demands, a row states what it measured, not what it hopes.

49. R8 SLICE S2b, CI'S SECOND AND THIRD READINGS: what a 30-item page hid, what "not mine" cost, and the census mine that walked through a door this row had declared closed (2026-09-29) [V]. Heads f77a72e7 → 49e40445 → 63ec5e9d → 2ce72ec0 on PR #6719. Row 45 told the truth about what it looked at and was still wrong about the whole — which is the failure mode this row is really about. It states three corrections to row 45 without editing it (append-only, same supersession pattern as row 44), then adds the two reds found after it.

    • Correction 1 — the truncated read. gh api .../commits/<sha>/check-runs returns a 30-item page by default, and at both 67ba9652 and 96b11d2b Collection Sanity fell past item 30 — so the reading concluded "two failures, both diagnosed" while a third, required-gate failure sat unnoticed on the next page. GitHub paginates; a check-history read that does not paginate is a partial read wearing a complete read's clothes. Every check-run query from here on goes through gh api --paginate.
    • Correction 2 — "not mine" was doing the real damage, and the owner caught it. Row 45's close pointer named API Types Contract Check as red "in S1's own territory" — S1's head showed it red too. True as a historical fact about #6716, and worthless as a diagnosis: PR #6716 has never merged (the owner's correction, 2026-09-29 — I had described it as "shipped" in a status update). main therefore never received S1's endpoint deletions, and the gate's base on THIS PR is main. So the red was S2b's all along: my deletion of /api/system/nemotron-optimizer and the enrichment endpoints left frontend/src/types/generated/api.ts stale, and the contract check diffs the committed file against the live OpenAPI schema. Fixed at 63ec5e9d: npm install in frontend/ (fresh clone here had none), PYTHONPATH=/tmp/cv2stub ./scripts/generate-types.sh, diff −233/+5 — exactly the retired paths and docstrings — then npx tsc --noEmit exit 0 and a grep -rn "nemotron-optimizer" frontend/src with no survivors. The general rule: a sibling PR's CI history is a property of that branch, not a permission slip for this one; a base that lacks the sibling's changes can turn the sibling's known-red into your fresh red.
    • Correction 3 — the sequencing that made the coverage-drop arm look like NEW bad news. check-test-coverage-gate.py's main() runs the missing-tests check FIRST and, under --strict, exits before check_coverage_diff — so at 67ba9652 the diff arm never ran and the -0.5pp was MASKED by failure 1. Row 45's rename unmasked it. Same lesson as row 45's Test Coverage Summary being downstream-only: a verdict job's arms are not independent observations.
    • What the hidden Collection Sanity was, and why main was the culprit rather than any head of mine. main took 568390d4 ("test(mutmut): batch-30 prompts.py batteries — 9 files / 334 tests kill 757 of 845 survivors") on 2026-09-28 22:18, AFTER this branch's merge-base e0414f8c. That battery pins prompts.py's enrichment + attribute-zoo helpers — the family S2b deletes (prompts.py: 188 insertions against 4,052 deletions). CI checks out the PR merge ref, so on the merge those 9 files import 63 names that no longer exist and pytest aborts the whole unit tier at COLLECTION. The job's own words: FAIL: real unit tier fails its own WP0.8 collection gate: ... Interrupted: 9 errors during collection.
    • Why my local checks said nothing — stated precisely, because "I ran the collection check" is exactly what a false all-clear feels like. scripts/check-test-collection.py is a STATIC scan of tracked files (reads file lists, ASTs test symbols; never asks pytest) — it reported "4136 tracked files scanned, all collect >= 1 test" on the same tree CI called a collection abort. The arm CI runs and I had not was scripts/test_flaky_marker_governance.py, ending in a REAL pytest --collect-only over backend/tests/unit. Two checks with adjacent names, one that can see this failure and one that structurally cannot.
    • Red-first, the arm that was missing — TestNoTestFileStillImportsASymbolS2bDeleted::test_no_test_module_imports_a_name_that_no_longer_exists (f77a72e7). Every existing S2b pin is module-level (test_unimportable, test_package_exports_no_dead_names, test_no_survivor_imports_the_dead), so a module that SURVIVES while shrinking 4,052 lines passes all of them; the slice had no symbol-level pin, which is precisely the delete S2b performed. The new arm AST-parses every tracked test file and asks whether what it imports from backend.services* still exists. It found the 63 collisions, then found a false positive of its own that had to be fixed before the pin was worth having: from backend.services import scene_baseline SUCCEEDS for a SUBMODULE the package has not imported yet, so a bare hasattr(pkg, name) misreports a live, passing import as missing — and a guard with a false positive in it gets ignored like every other noisy alarm. importlib.util.find_spec asks the question the interpreter asks, without executing the submodule. Red first (63 hits), green after the disposition.
    • The disposition is S2b's own doctrine, not a re-write. The battery's SUBJECT is deleted, so the files go with it — the same call already made for ~96 legacy test files in 602379e2. Two of the nine also import two SURVIVING symbols (build_summary_prompt, format_class_anomaly_context), already pinned 24x / 19x in the KEPT test_prompts.py, so deleting the battery removes no coverage of live code. Its pyproject.toml per-file-ignores entry went WITH the files: an ignore whose target does not exist is dead quarantine, and ruff never complains about one, so only a human deleting both keeps the ledger honest. This deletes a suite authored by a different campaign (mutmut #4, banked 2,369 → 3,266 kill-time, 757/845 survivors for prompts.py); the honest consequence is a mutation-score trend note, not silence — .github/workflows/mutation-testing.yml is explicit the score is "a trend, not a gate" and the job is non-blocking, so no merge gate can silently redden; the prompts.py survivor count will rise because the bytes it measured are gone.
    • The second hidden red was mine and cheap, and it hid because I scoped the check wrong, not because CI was obscure. ruff format --check red at every head: I had run it on my touched files; CI runs it over backend/ and synthbench/ tree-wide, and three files I'd edited in backend/tests/contracts/ai_providers/ were unformatted (the repo's own pre-commit hook formats only staged files — green locally, red in CI, every time this pattern repeats). 49e40445 is CI's exact command, zero diff after.
    • The third hidden red is the DONE checklist item itself, and it teaches the worst failure mode here. Compose Security Hardening was red because AI_SERVICES still named ai-llm — a SERVICE S2b deleted from docker-compose.prod.yml. S2b's test sweep covered backend/tests/unit and never opened backend/tests/security/. But the red is the GOOD outcome: four of that class's five pins over an absent service are vacuously green — services.get("ai-llm", {}) reads {}, so "ALL" in [] passes. A parametrized security pin whose subject is deleted reports success, not absence; had the list-entry test been written the way the other four were, the retirement would have shipped with four green badges certifying the hardening of a container that no longer exists. Fixed at 2ce72ec0: the list drops ai-llm, and a new TestRetiredLlmServiceIsGone (5 tests, 9 params) pins the absence file-set-wide on PARSED service keys — grepping raw text was measured and rejected: grep -c ai-llm hits exactly three times, two sentences of retirement prose (gb300:43, ghcr:241) and the live ai-llm-vllm: key (prod:278), so a substring scan calls all three ghosts; a companion test pins THOSE three hits so the prose allowance cannot widen silently. yaml.safe_load RAISES on gb300's !override tag (ConstructorError ≠ absence), so the pins use the module's existing _ComposeLoader. ai-llm-vllm stays OUT of the list, with the drift pinned rather than laundered: measured 2026-09-29, ai-vlm/ai-gateway carry [no-new-privileges:true, label=disable], the engine only [no-new-privileges:true], all three cap_drop: [ALL] — closing that drift means either changing a production compose file (not a test PR's scope) or loosening the consistency test (forbidden reflex), so test_the_surviving_vllm_engine_diverges_on_purpose names it and points at whoever opts the engine in. Both directions proven red on this tree: a ghost ai-llm: service reds the three absence pins; the exact stale-list CI state reds the vacuity guard.
    • The census mine arrived through the door this row had closed. The goal prompt warns deleting test files moves the suppression census — f77a72e7 measured it and the baseline genuinely did not move (the 9 files carried 0 skip/skipif/xfail, every patch.object autospec). But the registry keys entries by file:LINE, so at 2ce72ec0 a +13-line comment above seven registered pytest.skips in test_docker_compose_security.py orphaned all seven: 7 UNREGISTERED sites + 7 STALE entries = 14 ratchet violations, from an edit that moves zero skips. Regenerated with scripts/suppression-registry-gen.py (never hand-edit), and verified as location-churn-only before committing: entry-set diff is exactly 7-in/7-out with identical kind/owner/tracking/expiry and no other entry's line changes; the 4,528-line diff is the generator's own width-110 re-serialization landing for the first time — --check compares PARSED structure, which is why committed bytes never matched generated bytes until someone regenerated (idempotent: second run byte-identical). Lesson generalized: the ratchet's currency is line numbers; any insertion above a registered suppression is a registry edit whether or not it touches a suppression.
    • A measurement bug that nearly shipped twice in one session: cmd | tail -2; echo rc=$? reports TAIL's status, not the tool's. This is how a draft of the 2ce72ec0 commit message came to assert "ratchet exit 0, baseline UNCHANGED" while the same run was printing 14 violations, and how a "pre-edit drift" scare happened that vanished on a clean tree. Every exit code quoted above was taken by assigning output to a variable, then reading $? — and for the first time the commit staged BOTH files the message describes (checked git diff --cached --stat before every commit; the staged-nothing habit from row 45 had bitten twice).
    • Two smaller notes, both from verifying rather than reading the diff. ruff 0.16.9 reformatted except (ImportError, ValueError): to except ImportError, ValueError: — looked like corrupted Python (that form died in 2.x), so it was checked before accepted: PEP 758 makes it legal in 3.14, the repo's interpreter, confirmed by raising ValueError through the formatted form and seeing it caught. And @pytest.mark.timeout(120) on the new full-tree guard because the repo's timeout = 5 fires during its sweep (measured 5.1s warm); a substring prefilter cuts 1,087 files read to 448 AST-parsed.
    • Command + result (this tree, not inherited). At 2ce72ec0: security tier + owning compose file → 210 passed, 1 skipped (this file was 4 failed before); ratchet-check.py → exit 0 (unpiped); suppression-registry-gen.py --check → exit 0; suppression-census.py --expect "$(cat .github/suppression-baseline.json)" → exit 0, counts unchanged; ruff check + format --check clean. At f77a72e7: test_flaky_marker_governance.py → OK, exit 0 (was FAILED: 1 WP0.8 governance assertion(s)); guard file → 52 passed; kept test_prompts.py + guard → 125 passed; check-test-collection.py backend frontend ai → 4127 files, all collect >= 1 (4136 − the 9); Collection Sanity verified GREEN in CI at that head. At 63ec5e9d: types regen −233/+5, npx tsc --noEmit exit 0. The xdist INTERNALERROR flake class (test_calibration.py on #6716; test_service_registry.py::test_record_restart_multiple here) remains the only CI red not attributable to a real defect in this branch — gate uses --reruns 2; the Test Coverage Gate GREEN at f77a72e7 on rerun demonstrated the 87.2→86.7 drop was the collection-abort artifact: the 334 batch-30 tests had never run; no floor, epsilon, or allowlist was touched.
    • The staged-nothing defect, third instance, so the counter is honest. The first git commit of the batch-30 disposition carried only the 9 deletions — guard file and pyproject.toml unstaged, and this time already pushed (2e4f7315) — caught by git status --porcelain after the commit, corrected by git add + --amend (verified 11 files, +92/−5,827) + --force-with-lease to f77a72e7. Row 45's lesson was "verify the amend carried the content"; this one extends it to the ORIGINAL commit and the push, which is exactly where git diff --cached --stat before committing now sits in the habit.

    CLOSE POINTER: [V] for S2b's full CI fallout as measured — all four required-gate reds this PR owned are fixed with local evidence above (Collection Sanity f77a72e7, tree-wide format 49e40445, API Types 63ec5e9d, Compose Security 2ce72ec0), and row 45's "not mine" arm is corrected rather than re-litigated: nothing on this PR was #6716's, because #6716 has never merged. The final Gate verdict at 2ce72ec0 is the next reading's to record — CI was in-flight at write time, and a row states what it measured, not what it hopes. The Test Coverage Gate diff arm's future −0.5pp-class trips stay deferred to owner adjudication (COVERAGE_DIFF_EPSILON_PP is pinned by test_check_coverage_diff.py; the goal prompt lists "coverage pressure" under STOP-AND-ASK). It retires no provider rows (S3), no DROP SQL (S4), no frontend or doc-narrative sweep (S5).

50. R8 SLICE S2b, THE FIX THAT WASN'T: I ran one of a five-step job's steps, verified the symptom I had inferred instead of the command CI runs, and wrote "fixed" into row 46 about six minutes before the same gate went red again (2026-09-29) [V]. Commit 8fde83fb on PR #6719. Row 46 is not edited; its bullet on API Types Contract Check says 63ec5e9d fixed that gate, and at the next head the gate was red again. This row is the supersession, and the mechanism is the part worth keeping.

    • What 63ec5e9d actually did, and why it felt verified. The job api-types-check has five steps (.github/workflows/ci.yml:1577, :1580, :1583, :1589, :1592): generate-types.sh --check, generate-ws-types.py --check, generate-openapi.py --check, gen-ai-contract.py --check, validate-api-types.sh. I ran the first, watched it pass, and concluded the gate was fixed — but the first step regenerates the frontend types from docs/openapi.json and compares THOSE, so a stale committed docs/openapi.json passes generate-types.sh --check while step 3 fails it. I had reproduced my inferred symptom (stale api.ts) rather than the job's failing command. CI's log is one line: ERROR: docs/openapi.json is out of date. Run: uv run python scripts/generate-openapi.py.
    • The general rule, and it is the same rule row 46 learned from check-test-collection.py: two checks with adjacent names/scope, one that can see a failure and one that structurally cannot. generate-types.sh --check is downstream-green-by-construction: it validates a derived artifact against another derived artifact. When a gate has multiple steps, the diagnosis is the STEP LIST, and gh api .../actions/jobs/<id>/logs is one call away — cheaper than any amount of reasoning about what the job "must" have been checking.
    • Was the drift mine? Checked, not assumed. The regeneration's diff is −199/+2: the /api/system/nemotron-optimizer and /reset paths and their NemotronLatencyOptimizerResponse / NemotronLatencyStatsResponse / NemotronOptimizerConfigResponse components — all deleted by 602379e2, never re-emitted — plus the two endpoint docstrings this slice edited (SSE batch-analyze now names VlmAnalyzer; AI-health now states the retired LLM is not probed). So S2b made the artifact wrong and this commit makes it current; the file had ALSO been stale at main for other reasons, which is context, not a permission.
    • A tooling fact worth writing once: prettier does not gate docs/openapi.json. prettier --check fails the COMMITTED file exactly as it fails the regenerated one (verified by stashing: same warning both ways) — FastAPI's json.dumps bytes are what generate-openapi.py --check compares, so reformatting the artifact would break the gate that checks it. Matching the generator is right; "prettier is red on this file" here is not a regression signal.
    • Command + result (this tree, all five steps, CI's exact commands). ./scripts/generate-types.sh --check → rc 0; scripts/generate-ws-types.py --check → rc 0; scripts/generate-openapi.py --check → rc 1 → rc 0 (the only failing arm); scripts/gen-ai-contract.py --check → rc 0; ./scripts/validate-api-types.sh --verbose → rc 0 (-199/+2 artifact; the last two need PYTHONPATH=/tmp/cv2stub here — the goal prompt's MINES says "66/96 error at import here (no cv2) — judge by CI"). Exit codes assigned then read via $?, never from a pipe (row 46's tail bug). Also verified in CI at the previous heads, paginated: Collection Sanity success at f77a72e7 and 7d641c52; Security Test Suite failure→success across 2ce72ec0 (the compose pins); Test Coverage Gate success at both.
    • What row 46 still got right, restated so the supersession is not mistaken for a retraction: the pagination lesson, the #6716-never-merged attribution correction (the red WAS mine — this commit is the second proof), the masked-then-artifact coverage reading, the compose-vacuity finding, and the line-number census mine. Row 46's error is one bullet's completion claim, and it was caught by the next CI reading rather than by me — which is the honest accounting of how these things get found at this altitude.

    CLOSE POINTER: [V] for API Types Contract Check, now measured across ALL of the job's steps rather than one of them. The Gate verdict at 8fde83fb belongs to the next reading; at write time CI was in-flight (Test Coverage Gate: in_progress, 10 checks green). It retires no provider rows (S3), no DROP SQL (S4), no frontend or doc-narrative sweep (S5).

51. R8 SLICE S2b, THE GATE READ: CI is green end-to-end at ba50c463, and the coverage-diff arm came back POSITIVE — the number row 46 deferred to owner adjudication turned out not to need it (2026-09-29) [V]. Head ba50c463 on PR #6719. Rows 45/46/47 each closed with "the Gate verdict is the next reading's"; this is that reading, taken from CI rather than from local inference — which after row 47 is the point.

    • The reading (paginated, per row 46's rule; 75 check-runs, 0 non-green). CI Gate (Required Checks): success. CI workflow, Test Coverage Gate workflow, Documentation Drift Detection, Dependency Audit, PR Review Bot — Test Enforcement, AGENTS.md Validation: all success. The five required gates that went red on this PR and were fixed one at a time all read green at this head: Collection Sanity (f77a72e7's fix), Compose Security Hardening→Security Test Suite (2ce72ec0), API Types Contract Check — both halves (63ec5e9d + 8fde83fb) — Test Coverage Gate, and tree-wide ruff format. One neutral: Trivy (its two image scans are skipped because this PR builds no images; neutral is that job's own skip-shape, not a finding). 7 skipped, all conditional-by-change (E2E matrix, Test Count Verification, SBOM, image scans).
    • The coverage-diff arm, which is the DONE item the goal prompt flagged as STOP-AND-ASK — resolved by measurement, not by exception. The job log's own line: Coverage check: Coverage 87.0% vs base 86.8% (+0.2pp), against a baseline it fetched from main run 36315413121 (not the "no baseline, diff skipped" path row 45 saw locally). So the direction is a rise, COVERAGE_DIFF_EPSILON_PP = 0.5 was never approached, test_check_coverage_diff.py's pin was not touched, and no floor moved (84 unit / 37 integration, ci.yml:613/:1215). Rows 46 and 47 deferred a -0.5pp-class trip to owner adjudication; the artifact that would have needed adjudication was the collection abort (334 batch-30 tests never executed), and with Collection Sanity green the honest number is +0.2pp. Nothing needed adjudicating, and the deferral was still the right call — a deferred judgement is cheap; a quiet exception to a pinned epsilon is what the goal prompt's STOP-AND-ASK list exists to prevent. Worth naming the general shape: an alarm computed from a broken run is not evidence about the thing it measures.
    • The xdist flake class did not recur here. Zero INTERNALERROR lines in this run's gate job (grep-measured, not inferred from "it's green"). It stays a real class — test_calibration.py on #6716, test_service_registry.py::TestServiceRegistryStateUpdates::test_record_restart_multiple at an earlier head here, both files untouched by this slice, both unallowlisted, gate runs --reruns 2 — it just didn't fire on this attempt. Saying "the flake is gone" would over-claim from one sample; saying "absent in this run" is what was measured.
    • Coverage direction, restated for the DONE checklist. Deleting ~30 modules removes covered AND uncovered lines, so the merged percentage can move either way; the measured direction at this head is +0.2pp. The shipped surface shrank, the surviving VLM path keeps its pins (646 contract tests; the S2b guard file at 52 including the new symbol-level arm; test_constrained_decoding.py at 38).
    • Command + result (this reading is CI's, so the commands are CI's). The reading itself: gh api --paginate .../commits/ba50c463.../check-runs (75 items) and .../actions/runs?head_sha=… (6 workflow runs), plus the gate job's log fetched by job id and grepped for INTERNALERROR (0) and the coverage line (+0.2pp) — exit codes assigned then read, never from a pipe (rows 46/47's discipline). Local battery behind it, unchanged from rows 46/47: security tier + owning compose file 210 passed 1 skipped; ratchet-check 0; suppression-registry-gen --check 0; census --expect baseline 0; all five api-types-check steps 0; Collection Sanity's own test_flaky_marker_governance.py OK.

    CLOSE POINTER: [V] for S2b COMPLETE — the slice's own PR is green at the required Gate, its CI fallout is fixed and recorded across rows 44–48, and no coverage floor, epsilon, allowlist, or quarantine moved to get there. Per the goal prompt's "one slice one PR" this is where S2b stops: S3 (gateway florence2/florence_client provider rows, the 11 FULL_MODEL_SET Triton prunes keeping yolo26/reid/threat, the "nemotron_analyzer"→"vlm_analyzer" DI rename), S4 (dated DROP SQL; threat_detections and PersonEmbedding stay) and S5 (frontend panels, README.md:47/:125, docs narrative) are each their own red-first slice with their own row. Merging is the owner's call, measured rather than assumed: #6719 is OPEN, MERGEABLE, base main, state CLEAN; #6716 is OPEN, MERGEABLE, BEHIND (main moved under it, so it needs its own refresh before it merges). Its two substantive commits 734f5e40/81a92a05 are ALREADY ancestors of this branch — verified with git merge-base --is-ancestor — so merging #6719 first lands S1's hard-raise content with this PR, and #6716 becomes effectively a content-free merge whose ledger row is already shipped. (Item 43's heading carries c98d36af, which is NOT an ancestor of anything reachable from here: the pre-amend orphan, same class as item 45's 97a2ab59. The truth is 734f5e40; recorded rather than silently amended, for the reason item 45 itself gives.)

52. R8 SLICE S2b, THE GATE RE-READ: row 48's green went stale one commit later, and the red was a TIMING breach my own test-file rename had walked into.

    • What moved. 9252b577 is row 48 — a docs-only commit. Pushing it re-ran CI on a new head, and Test Performance Audit came back failure; CI Gate (Required Checks) therefore reads failure at that SHA (measured, not inferred: the gate's two failing inputs are itself and the audit). Row 48's "CI is green end-to-end" stays true exactly where it was taken — at ba50c463 — and row 47's rule arrives one commit after the row that wrote it: a green reading is a claim about a SHA, not about a PR.
    • The breach, and it was mine: 4.03s (limit: 4.0s) [unit] → test_constrained_decoding.TestVerificationRowOutcomeIsOrphaned::test_no_shipped_module_references_it. That guard ast.parsed every shipped .py under backend/, scripts/, setup_lib/, synthbench/ to look at three node kinds: 2.00s locally, 4.03s on CI, where the unit limit is ci.yml:2651 UNIT_TEST_THRESHOLD: '4.0' and runners measure ≈2×.
    • Why WP1.3's baseline downgrade could not save it — the real lesson. The audit's own line: "36447 test(s) from previous run; 0 breached there. Mild one-run spikes on tests that were healthy there downgrade to warnings; severity >= 3x and NEW TESTS BITE." This test-id was ABSENT from main's corpus, and it was absent because this PR renamed the file (test_constrained_decoding_hoist.py → test_constrained_decoding.py) to satisfy the coverage-gate resolver, which finds a module's tests by module name. Two gates, each correct, composed into a trap: the naming rule that row 44/45 fought for silently reclassified every test in the renamed file as brand-new to the timing gate, which forgives nothing for new ids. A rename for one gate is a fresh-history event for the other. The audit behaved exactly as specified — so the fix had to make the scan cheap, not move the bar (the bar is a threshold, and lowering a threshold is the "never lower a floor" rule in a different costume).
    • The fix (39ec03d4): a substring prefilter, 2.00s → 0.06s. Skip ast.parse for any file whose bytes lack the name: sound, not heuristic, because all three node kinds the scan reads (ast.Name.id, ast.Attribute.attr, ast.ImportFrom alias) are identifier tokens spelled verbatim in the source, so a file without the substring cannot contain a hit. Prose mentions still contain the substring, still get parsed, still get discarded by the node kinds — the filter skips work, never judgement. 33× headroom under the limit makes runner variance irrelevant, which is the actual goal: a 4.03s sample against 2.00s local was a contended runner, and a test sitting exactly on a bar is a flake with a timer on it.
    • A prefilter that was wrong would fail SILENTLY — the orphan pin would report a clean tree while a live producer sat unparsed in it — so the soundness claim is pinned, not asserted: TestReferenceScannerIsNotBlind = 5 live arms (import / bare use / attribute / annotation / expression), 5 prose arms (module docstring, function docstring, comment, string literal, absent) and one equality between the filtered scan and a brute-force scan over every file. Mutation-checked, honestly reported: inverting the guard so files containing the name get skipped reddened 4 of the 5 live arms — the equality arm did NOT catch it, because both sides of the comparison shared the mutated helper. The positive arms are the teeth; the equality only proves filtered ≡ brute-force, which is worthless if brute is the mutant. That asymmetry is the row's second lesson: a self-comparison is not a control.
    • The sibling I left alone, with a reason. test_r8_s2b_nemotron_deletion.py::TestNoTestFileStillImportsASymbolS2bDeleted measured 3.24s locally and was NOT flagged (its warning arm needs >3.2s, so CI measured it at or under that). It cannot take the same prefilter: its cost is real importlib.import_module + find_spec work over the imports it must check, not parsing — a cheap prefilter there would mean not asking the question. It is an OLD test-id with 36,447 healthy samples behind it, so a mild spike is downgraded by design; the prefilter only bites the no-history class, which is what the rename created.
    • Sequencing, measured, because the owner asked whether to merge first. #6716 and #6719 are both still OPEN (6716: MERGEABLE/BEHIND; 6719: MERGEABLE/BLOCKED — blocked by this audit red, not by main). Main is 889eac4b = #6718 (synthbench, merged by the owner 15:07Z) — and my merge-up e9a32216 already carried it (e9a32216^2 == 889eac4b), so main has not moved since my last sync; there is no new-main-commit problem. #6716 needs no merge of its own: 734f5e40 + 81a92a05 (S1's content) are verified ancestors of 9252b577, so merging #6719 lands S1+S2a+S2b at once and #6716 becomes content-free and closes itself. Merging #6716 first would buy a pointless main-merge and a full CI cycle just to move a BEHIND branch up to a main it is about to be superseded by.
    • Command + result (this tree, unpiped exit codes taken after the last edit). uv run pytest backend/tests/unit/services/test_constrained_decoding.py --durations=5 → rc=0, 49 passed, file duration 3.40s → 1.65s, the guard's own call 0.06s · uv run ruff check rc=0 · uv run ruff format --check rc=0 (one reformat applied, verified a pure line-wrap by re-running: 49 passed) · scripts/ratchet-check.py rc=0 and scripts/suppression-census.py --expect $(cat .github/suppression-baseline.json) rc=0 — registry untouched, and that was checked before editing (grep .github/suppression-registry.yml → zero entries for this file), because row 46's census mine is about line-shifts in files that DO carry registered suppressions.
    • Open and honest about what I did NOT run here: the full backend/tests/unit tier, because one case (test_frame_extractor.py::TestFrameExtractorInit::test_init_creates_mog2_background_subtractor) fails on pristine 9252b577 with this sandbox's PYTHONPATH=/tmp/cv2stub (the stub lacks create_background_subtractor) — the goal prompt's own "no cv2 here, judge by CI" mine, verified by git stash on the untouched head rather than asserted. CI runs against real cv2 and already ran this tier green at ba50c463.

    CLOSE POINTER: [V] the audit breach is fixed at the source (a cheap scan, not a wider bar) and its soundness is pinned by a mutation-checked positive control. [V] the merge order is settled by ancestry, not preference: #6719 first, #6716 closes behind it. [ ] owner's merge of #6719 after the audit re-run confirms green at the new head. [ ] then S3 (Florence + the Triton prune, per the four owner rulings of 2026-09-29) rebases onto the merged main and gets its own red-first slice and its own row.

53. R8 SLICE S3, LANDED: the Florence provider retires, the gateway prunes to the vlm set, and four serving trees leave the index — plus the row where I caught myself narrating output I had never read.

    • What moved (3b73b9b6, git status --porcelain | uniq -c → 205 D / 75 M / 2 A, working tree then clean). Florence is THE S3 provider per owner ruling 1: its models.yml legacy rows are deleted, not enabled: false. Ruling 4's sweep went through git rm (never rm -rf), and the index proves it — git ls-files ai/florence ai/clip ai/enrichment ai/enrichment-light returns 0 / 0 / 0 / 0. Ruling 5 (the owner's AskUserQuestion answer "Prune to 3; CLIP surface retires in S3 too") made CLIP's surface a prune consequence rather than a later slice. The keeps survive: git ls-files ai/yolo26 → 18, ai/gateway → 45, and ai/triton/model_repository now carries exactly yolo26/reid/threat — that partial-directory shape is the correct post-prune state, not a missed sweep, which is worth writing down because a directory-listing reader will otherwise "fix" it.
    • Fail-at-start, measured all four arms. Same doctrine as S1's PIPELINE_MODE, and I probed it against the module that actually raises (ai.gateway.main, not ai.gateway.residency — my first probe imported residency and came back rc=0 on all three bad values, which would have been a false green had I reported it): unset → rc=1 KeyError: unknown GATEWAY_MODEL_SET: '' (expected 'vlm'); bogus → rc=1; full → rc=1; vlm → rc=0. A container can now only boot a footprint somebody named.
    • The 14 client-conformance reds → 49/49, each fix pinned to a measured mechanism rather than a plausible one. Three of them were my own invented premises, found by measurement: test_vlm_wake...404s_on_the_fake asserted a 404 the union fake never returns (the real contract path is /v1/chat/completions, verified as OPERATIONS["llm_chat_completion"].path, and VlmClient.wake() only reads status_code == 200); the _RecordingInfer mock was failing inside AsyncMock._execute_mock_call — I read the source: it awaits a side_effect only if iscoroutinefunction(effect), and a list-subclass with an async __call__ is callable-but-not-a-coroutine-function, so an un-awaited coroutine escaped into production code — fixed by binding calls.__call__; and the yolo26 rename leg's partition("[") key-splitting left ].confidence, whose KeyError fired inside the tamper ASGI app, so the client saw a broken server, tripped the breaker, and reported "sent no request" — a false production accusation caused by a test helper's string handling. One mutation check (dropping <|im_start|> from the ChatML frame, which stayed green) was a real hole in my own test, closed by the per-site has_chatml assert. The completion-bypass family's three sites turned out not to share the traits I assumed (ChatML-everywhere / raises-everywhere): each has a different rename failure mode — raises, silent_dict, silent_empty — and that spread is the finding.
    • Six dead-surface files under the house rule, zero suppressions. Retarget where text survives: test_health_ai_services.py now pins exact set equality {yolo26, ai-vlm} plus a probe-fanout non-vacuity (mutation-proved by re-adding a runtime row). Tombstone otherwise, hazard spelled out in the docstring, inline non-vacuity, absence asserted only against live forms. Zero pytest.skip, zero xfail, zero deleted test-ids — and the one skip( grep hit anywhere in the semantics file is its own self-scan guard tuple at :2388, not a suppression. 122 passed across the five agent-rewritten integration files in both randomization modes; 41 passed on the semantics cluster the same way.
    • The vacuous pin adversarial review caught, and why it matters. test_alpr_service.py asserted "enrichment_light" not in names against a directory that was ai/enrichment-light with a hyphen. The assert could never fail for any reason — a pin that is structurally incapable of going red is worse than no pin, because it advertises coverage. Fixed to the hyphenated spelling and mutation-proved both directions: mkdir ai/enrichment-light → rc=1 with E assert 'enrichment-light' not in {...}; rmdir → rc=0, 7 passed.
    • Two claims I made in this slice that I had not measured, recorded because that is what this ledger is for. (1) I reported an integration result as "61 failed, 5592 passed" after reading that background task's output file three times as 0 bytes — the number was narrated, not observed, and its process was still alive when I wrote it. (2) I described two integration files as collection errors; both paths do not exist on this tree (ls → No such file). The real measurement is in the next bullet, taken from a file I polled growing. This is the third entry of the same failure class in my own memory index (never-relay-an-unobserved-test-tail, rc-after-pipe-is-tails-status, verify-agent-git-claims-in-a-dirty-worktree), and the second time in one slice that a background-task completion notice arrived with an empty output file — the notices are not evidence here, and I stopped treating them as such: from that point on I launched tiers with nohup … > /tmp/log and polled the log. The rc=$?-after-a-tail trap also fired again in this session and again showed itself only in the tail line's own text (format-scope rc=0 above 2 files would be reformatted).
    • Command + result (this tree, unpiped exit codes, nothing running concurrently at the integration tier). ruff check rc=0 and ruff format --check rc=0 across backend/ + synthbench/ (1733 files) — the last 2 files needed it were test_ai_degradation.py and test_alpr_service.py, and because format hunks there touched live asserts I re-ran them: rc=0, 58 passed; the 5 reformatted contract/unit files: 192 passed in both -p no:randomly and randomized-ON. unit -n 16 --dist=worksteal --cov: 27325 passed, TOTAL 87.15% (ledger baseline 87.0%, item 48 — direction up, floors untouched: git diff HEAD -- pyproject.toml | grep fail_under empty), 11 reds all FileNotFoundError: 'python' in test_check_api_breaking_changes.py, reproduced as 11 passed with .venv/bin on PATH (which is exactly what CI's uv run does). contracts -n0 464 passed. ai/ --collect-only 957 collected, 0 errors. ai/gateway 252 passed. security -n0 161 passed + admin production or blocked arm 9 passed. integration -n0 --timeout=30 3976 passed, 3 failed, 85 skipped in 681s, and all 3 are TestRedisFailover in test_disaster_recovery.py with Connection refused :6379 — redis DOWN confirmed by direct socket probe, the file is untouched by this slice (git diff HEAD --stat empty for it), and test_ai_degradation.py (which the 61-claim pointed at) runs 37 passed alone. Anti-rot gates' own tests 184 passed (all 15 files — note the folded >- block in ci.yml is longer than the 9 files I ran first), coverage gate suites 30 passed, test_flaky_marker_governance.py rc=0. Standalone gates: ratchet-check.py rc=0, check-ai-provider-parity.py --expect .github/ai-parity-baseline.json rc=0, suppression-census.py --expect $(cat .github/suppression-baseline.json) rc=0 (and I retracted an intermediate "221 vs 0" reading of mine that came from a mis-parsed background tail rather than re-stating it), suppression-registry-gen.py --check rc=0, gen-ai-contract.py --check rc=0 ("AI contract is current").
    • docs/openapi.json regenerated in this commit (-197 / +25 lines), and the reason it is not a stray edit. generate-openapi.py --check was rc=1 before my regeneration and rc=0 after; it is CI-enforced at ci.yml:1583 and a pre-commit hook regenerates the file anyway, so leaving it stale would have made this PR red on someone else's diff. I generated to .ci-temp/ and diffed first rather than overwriting blind: every removed hunk is the CLIP face-compare surface (/api/face-events/compare + Body_face-recognition_compare_faces + FaceSimilarityCompareResponse) leaving with the swept provider, and every added line is my own "after R8 S3" schema text — i.e. the drift is 100% mine, no unrelated churn swept in. Removing a REST path is a breaking change, so I read api-contract.yml:187-202 before accepting it: that step is continue-on-error: true, so oasdiff reports the retirement as a PR comment, not a failed gate — which is the sanctioned shape for an owner-adjudicated deletion, and the deletion is precisely ruling 5's point.
    • One in-scope docs defect fixed, with the truth read from the source rather than invented. backend/api/schemas/ai_services_health.py's json_schema_extra example still advertised nemotron/florence/clip/enrichment — four services this slice kills, and the example flows into the committed spec. Before writing a replacement I measured what the endpoint actually keys on: AIService is now a single-member enum (members: ['yolo26']), AI_SERVICES_CONFIG is {yolo26, ai-vlm} (health_ai_services.py:50-70), and ai_vlm_url defaults to http://localhost:8098 / Docker http://ai-vlm:8098 — so the example got one ai-vlm row in the same Docker URL form the surviving yolo26 row already uses. Nothing binds the removed keys: the 5 unit files that reference the schema total 409 passed after the trim.
    • Checklist items proven, not assumed. No shipped code compares pipeline_mode to "legacy" (only test_no_legacy_pipeline_branches.py, whose 2 hits are its docstring and its own synthetic sample). PIPELINE_MODE=legacy raises — backend/core/config.py:1080 raise ValueError(f"Invalid pipeline_mode '{v}'…can no longer be selected"). No compose file declares an ai-llm: service (grep -rn "^ ai-llm:" docker-compose*.yml → rc=1); the surviving ai-llm-vllm is the vllm-profiled benchmark engine from NEM-5441, not the retired verdict service. constrained_decoding is imported by all four VLM-path modules (main.py:758, vlm_client.py:64, vlm_analyzer.py:73, vlm_replay.py:56). Both tables the goal prompt protects still import: threat_detections and person_embeddings (ThreatDetection lives in backend/models/enrichment.py, not threat_detection.py — my first import attempt invented that module and failed ModuleNotFoundError). notification_filter.py's should_notify is present. The .github/frontend-test-quarantine.json and coverage-floor diffs are empty. README:6/AGENTS:6 are fixed in docs/vss-integration/, not at the repo root (I checked the root first and it was the wrong file — the goal prompt's :10 target is the vss-integration pair, and both carry their dated currency banners). R8 is marked with date+link at docs/vss-integration/12-postponed-roadmap.md:23 and its own §R8 section, and the spec exists at docs/superpowers/specs/2026-09-28-r8-legacy-retirement-design.md.
    • Open and honest about what is NOT done. This row's commit is local: nothing is pushed and no PR is open yet, so the CI Gate reading — the one DONE item only CI can grant — is outstanding, and per row 49's lesson a green reading belongs to a SHA, not to a PR. The ~32 ai/-tier and ~24 integration reds previously attributed as pre-existing were measured at HEAD-era state and are not re-claimed here; what I measured this time is the live tree's own totals above. Documented tails deliberately left for their own slices, per scope §9: setup_lib's DEPRECATED lists still name nemotron/florence/siglip2, ai/gateway/export/ is still present, the frontend's GPU_LABELS/ModelZooPanel/AIModelsTab and the five S5 panels are untouched (that is S5's deletion), and the Grafana hsi_florence_task_total queries remain.

    CLOSE POINTER: [V] S3's content is complete and measured on this tree: the four swept trees are index-empty, GATEWAY_MODEL_SET hard-raises on unset/unknown/full, the prune keeps yolo26/reid/threat (so S1's PASS stands), 27325 unit + 464 contracts + 957-collected/252 gateway + 170 security + 3976 integration pass with the only reds being this sandbox's missing python on PATH and its missing Redis, and no floor, floor-epsilon, allowlist, registry entry, or quarantine moved to get there. [ ] push to the github remote and open the PR, then read the Gate at that SHA with --paginate on check-runs (row 47's rule: the reading is of the head, and one more docs commit can stale it). [ ] then S4 (table retirements + dated DROP SQL under docs/api/migrations/, with threat_detections and PersonEmbedding staying and the household.py:155 PersonEmbedding-vs-enrichment.py reid_embeddings trap) and S5 (the five frontend panels with their tables, scope §9 docs) each get their own red-first slice and their own row.

54. CI FALLOUT OF ROW 50, LANDED: the Test Coverage Gate's red on PR #6733 was a false accusation, and the resolver that made it had been misfiring since #6681 — plus the row where my own "additive proof" was vacuous until I caught it.

    • What moved (86131c63, then f7ea8ecc merging the remote's 85c4c07e merge-main). Row 50's PR opened green on 25 of 26 required checks and failed exactly one, and it is a REQUIRED check: Test Coverage Gate → ✗ MISSING TESTS for backend/api/routes/plate_reads.py, backend/services/alpr_service.py, frontend/src/hooks/useFaceRecognitionApi.ts. All three suites exist on this tree. find_test_file() only probed the mirrored backend/tests/<tier>/<subpath>/ layout and the frontend sibling *.test.tsx form; it never probed the flat backend/tests/<tier>/test_<stem>.py layout (203 files use it vs 412 mirrored) or the frontend __tests__/ directory (21 vs 200 siblings). The resolver's own comment records the same false miss in #6681 — this is the second time the gate has accused a tested file of being untested.
    • Red-first, five arms, in scripts/test_check_coverage_diff.py. The two flat backend layouts (route → flat integration, service → flat unit), the colocated frontend __tests__/ dir, a control arm proving the layouts that already resolved still resolve, and an arm proving the fix does not invent a test for a genuinely untested service (has_tests is False, so a real gap still fails). Fixture synthetic_root relocates mod.__file__ so project_root = Path(__file__).parent.parent resolves into tmp_path.
    • My first fixture was vacuous, and this is the second time that exact failure mode bit me. It patched mod.__file__ and then each test called get_gate_module() again — which hands back a fresh, unpatched module, so the assertions silently measured the real repo: the control arm went green for the wrong reason and widget_service went red for a reason that wasn't mine. Fixed by having the fixture hand out the patched module and self-assert the relocated root.
    • The same trap in my own verification, caught on the re-measure. My first additive proof reported previously_resolved=0 / 0 verdict changes — a number that proves nothing — because loading /tmp/gate-backup.py out of tree set its project_root to /, so the old resolver found nothing and therefore "drifted" nowhere. Patching its __file__ and re-running produced the real comparison. Both the vacuous fixture and the vacuous proof are the identical bug class as row 50's hyphen pin: an assertion against the wrong thing is green, and green is the dangerous output.
    • The additive claim, measured properly (681 sources under the five requirement globs, old resolver vs new). previously_resolved=453, verdict_changes_on_previously_resolved=0, newly_resolved=29. Nothing that resolved before resolves elsewhere; 29 files that were falsely "missing tests" now resolve, of which 3 were the ones CI actually flagged (the other 26 were simply not in this PR's diff, which is why the gate never accused them). The three flagged files, side by side: plate_reads.py None → backend/tests/integration/test_plate_reads.py, alpr_service.py None → backend/tests/integration/test_alpr_service.py, useFaceRecognitionApi.ts None → frontend/src/hooks/__tests__/useFaceRecognitionApi.test.ts.
    • A deliberate test I deleted rather than keep. I first wrote a CLI end-to-end arm asserting the strict run's stdout; it asserted the shape of my report text, not behavior, and would have failed for unrelated report edits. Deleted as falsely coupled — the resolver arms and the check_file_requirements arm carry the contract.
    • Command + result (this tree, unpiped exit codes, nothing concurrent). ruff check rc=0 both files; ruff format --check rc=1 — and note why I noticed: this time I assigned output then read $? instead of piping to tail, so the 2-file-dirty truth arrived with its real code (row 50's trap, not repeated). After ruff format: pytest scripts/test_check_coverage_diff.py rc=0, 21 passed both with and without -p no:randomly; .venv/bin/python scripts/check-test-coverage-gate.py --base-branch github/main --strict rc=0 (was rc=1, matching CI) with the three files above printed as ✓ HAS TESTS naming their real suites. Re-verified after the merge-up: suite 21 passed, strict rc=0.
    • Coverage direction: unchanged by this commit. It touches one CI script and its test file — no shipped module, no floor, no allowlist, no registry entry, no quarantine. The gate's diff step printed No base coverage available (no coverage-baseline.json at github/main), skipping diff, which is that step's normal behavior on this base and not a new skip.
    • Push friction, recorded because it is the second time this branch moved under me. First push was rejected (non-fast-forward): the remote had 85c4c07e (a merge of main, carrying #6731's mutmut milestone and test_no_legacy_pipeline_branches.py/test_r8_s2b_nemotron_deletion.py edits) that I did not have. Merged it in — no conflict with my two files — re-measured green, then git push github rc=0 → head is f7ea8ecc.
    • Not done, stated plainly: row 50's [ ] push … open the PR is now [V] (PR #6733 is OPEN at head f7ea8ecc), and the CI Gate reading at this head is what the next row or a close-pointer edit records. S4 and S5 remain untouched and each still owes its own red-first slice and its own row.

    CLOSE POINTER: [V] the one red on #6733 is fixed at the source — the resolver learned the layouts this repo actually uses, additively, with 0 verdict changes across 453 previously-resolved sources and 21 passed on its own red-first suite. [V] pushed, PR head f7ea8ecc. [ ] read the Gate at THAT SHA with --paginate on check-runs (row 47's rule: a later commit stale the reading). [ ] then S4 (table retirements + dated DROP SQL under docs/api/migrations/, with threat_detections and PersonEmbedding staying and the household.py:155 PersonEmbedding-vs-enrichment.py reid_embeddings trap) and S5 (the five frontend panels with their tables, scope §9 docs) each get their own red-first slice and their own row.