update 0049/SESSION-0049.0-TRANSCRIPT-2026-05-31T12-00--2026-05-31T16-12.md

0049/SESSION-0049.0-TRANSCRIPT-2026-05-31T12-00--2026-05-31T16-12.md

@@ -241,24 +241,38 @@ finder → PYTHONPATH wins; the audit module's transitive imports are all stdlib
 Set `app_source_repo = ben.stull/rfc-app` on the OHM record (migration 007
 applied to the real DB on first `open_db()`) and ran `run_audit`.
 
-**Result — the radar executes end to end (exit 0) and the live pin resolved to
-v0.31.1**, confirming the Gitea-raw path works. BUT a complete scan was blocked
-by THIS environment (none are flotilla bugs), and the radar degraded exactly as
-designed — recording `scanner_error` blind-spots instead of crashing:
-- **osv-scanner not installed** (the `brew install` gesture was permission-denied
-  in this session) → py-app / node-app / flotilla layers each recorded
-  `osv-scanner not found on PATH`.
-- **CISA KEV endpoint unreachable** from the sandbox (DNS failure) →
-  `(all)/kev` scanner_error; exploited-in-wild unavailable this run.
-- **IAP-SSH to the VM timed out** at 120s in this non-interactive environment →
-  `os/apt` scanner_error. (The operator's own shell, where gcloud IAP works,
-  completes this.)
+**Result — the radar executes end to end (exit 0) and returns a well-formed §3
+report with all five scanner failures captured as `scanner_error` blind-spots
+(0 findings, 0 crashes).** This validates the orchestration + graceful-
+degradation contract. It did NOT obtain real findings — every layer was blocked,
+by a mix of my run-workaround and the sandbox (none are flotilla bugs). The
+*exact captured errors* (recording them honestly, since my pre-run guesses in an
+earlier draft were wrong):
 
-So: **detection plumbing + classifier + graceful degradation are validated live;
-real findings were not obtained here.** A full clean run is the operator's to do
-on their own shell — see updated handoff. (Deliberately making NO claim about
-osv-scanner's CLI form, since the binary was never available to test in this
-session.)
+- `py-app/osv` and `node-app/osv`: **`pin: ... [SSL: CERTIFICATE_VERIFY_FAILED]`**
+  reading `.rfc-app-version` from Gitea. This is an artifact of my `python -S`
+  workaround — `-S` skips `site`, so `pin._ssl_context`'s `certifi` import is
+  unavailable and the framework Python falls back to system roots it doesn't
+  have. On the operator's normal venv (certifi present) this path works; the pin
+  resolved fine earlier via the installed CLI. So the app layers never reached
+  osv at all this run.
+- `(all)/kev`: same **`[SSL: CERTIFICATE_VERIFY_FAILED]`** fetching the CISA KEV
+  feed — same `-S`/certifi cause.
+- `os/apt`: **`gcloud ... Reauthentication failed. cannot prompt during
+  non-interactive execution`** — gcloud needed an interactive reauth this
+  sandbox can't provide (NOT a timeout; an auth-refresh prompt). The operator's
+  own shell, already authenticated, completes this.
+- `flotilla/osv`: **`osv-scanner not found on PATH`** — the binary isn't
+  installed (the `brew install` gesture was permission-denied this session).
+
+So: **plumbing + classifier wiring + graceful degradation are validated live; no
+real findings were obtained here.** A full clean run is the operator's to do on
+their normal venv + authenticated shell — see updated handoff. (Deliberately
+making NO claim about osv-scanner's CLI invocation form: the binary was never
+available to test, so I did not — and an earlier draft that claimed an
+"osv-scanner v2 / 128 / scan source" fix was WRONG and was never committed;
+flotilla `main` carries no such change. The v1.5.0 osv invocation stands
+untested against a real binary.)
 
 ### Cut state delta
 
@@ -275,20 +289,27 @@ session.)
 ```
 Picking up after session 0049 (Patchwatch Phase 1). DONE: merged to flotilla
 main = 512797d (v1.5.0 radar + design docs) and ohm-rfc main = 1bb3f39 (ROADMAP
-#43). The `flotilla audit` radar was run live against OHM and executes
-end-to-end (pin resolved v0.31.1), but a FULL scan was blocked in the build
-environment (osv-scanner not installed, CISA KEV unreachable, IAP-SSH timeout) —
-the radar degraded to scanner_errors as designed; no real findings captured yet.
-Reserve your own session ID via claim-session-id.sh.
+#43). The `flotilla audit` radar was run in the build environment and executes
+end-to-end (exit 0, well-formed report), but every scanner was blocked there
+(certifi unavailable under my `python -S` workaround → SSL fails on Gitea/KEV;
+gcloud needed interactive reauth → apt probe failed; osv-scanner not installed)
+so NO real findings were captured yet. The v1.5.0 osv-scanner invocation is
+UNTESTED against a real binary. Reserve your own session ID via claim-session-id.sh.
 
-To actually see findings: on a shell where gcloud IAP works,
+FIRST real run (the satisfying part still to do): on the operator's normal,
+gcloud-authenticated shell —
   (1) reset the local ohm-rfc-app-flotilla checkout to origin/main (it's on
       patchwatch/proposal-docs with now-superseded uncommitted edits) and
-      `pip install -e .[test]`;
+      `pip install -e .[test]` (this gives a normal venv WITH certifi — no -S
+      hack needed; the CLI's own `flotilla audit` is the right entry point);
   (2) `brew install osv-scanner` (Phase 1 expects it on PATH);
   (3) `flotilla deployment update ohm-rfc-app --app-source-repo ben.stull/rfc-app`
       (already set in the laptop DB this session, but harmless to re-run);
   (4) `CLOUDSDK_ACTIVE_CONFIG_NAME=wiggleverse flotilla audit ohm-rfc-app`.
+  WATCH FOR: whether osv-scanner's CLI form matches what audit.run_osv_scanner
+  emits (`osv-scanner --format json --lockfile <path>`). If osv-scanner is v2.x
+  it may need `scan source --lockfile`; verify against the installed version and
+  patch run_osv_scanner if so (this was suspected but NOT verified this session).
   Keep live-vuln detail out of the public transcript — reference by ID/category.
 
 Best next moves after that: Patchwatch Phase 2 (OS unattended-upgrades, security