[16/36] Record OC-050 OC-090 OC-100 supervisor audit

[cjohnsto-nz]

---

This is part 6 of 21 in a stack made with GitButler:

•  21  [22/36] Release 0.8.0 with packaged PDF.js preview #54
•  20  [21/36] Complete OC-070 protocol surface polish #56
•  19  [20/36] Record final OpenCollection supervisor acceptance #53
•  18  [19/36] Add OC-110 runtime authoring UX #52
•  17  [18/36] Add OC-080 runtime lifecycle and OC-110 task setup #51
•  16  [16/36] Record OC-050 OC-090 OC-100 supervisor audit #50 <-- current
•  15  [15/36] Add OC-050 auth and transport support #49
•  14  [14/36] Add OC-100 request type UX #48
•  13  [13/36] Add OC-100 request type UX task #47
•  12  [12/36] Add OC-080 and OC-090 task tracks #46
•  11  [11/36] Record OC-010 through OC-040 supervisor audit #45
•  10  [10/36] Add OC-020 WebSocket support #44
•  9  [09/36] Add OC-010 GraphQL support #43
•  8  [08/36] Require demo server fixtures for parallel tracks #42
•  7  [07/36] Record OC-000 and OC-060 supervisor audit #41
•  6  [06/36] Add OC-060 schema round-trip validation #40
•  5  [05/36] Add OC-040 runtime scripting support #39
•  4  [04/36] Add OC-090 gRPC streaming support #38
•  3  [03/36] Add OC-030 gRPC unary protobuf support #37
•  2  [02/36] Add OC-000 protocol dispatch foundation #36
•  1  [01/36] Add OpenCollection agent plan #35

[APKiwi]

Verdict: approve. Both claimed fixes are real and verified:

• The inherited-boolean bug is genuine: (settings?.followRedirects !== 'inherit' && settings?.followRedirects) ?? config.get(...) evaluates to false for 'inherit' (false && x is false, false ?? y is false), silently disabling redirects/encoding for any inheriting request. _resolveInheritedBoolean (httpClient.ts:341-350) fixes both booleans and the regression test locks it in. Good catch.
• The .vscodeignore exclusion for fixtures/*.key correctly stops packaging the demo private key into the VSIX. It remains in the git tree and history, and inlined in the test file, see the note on the OC-050 PR.

Two notes: the audit's "sanity-check completed tracks" did not surface either of the two significant issues in the tracks it audited (the cross-origin redirect credential leak in OC-050, the gRPC silent edit-loss in OC-100), so treat the acceptance as build/test verification rather than a security pass. And the precise counts baked into the narrative are already drifting (41/41 here vs 42/42 in the previous ledger entry).

[APKiwi]

Re-review (whole-stack pass, per REVIEW_GUIDE.md)

The two fixes this PR records are real and verified: the inherited-boolean bug (_resolveInheritedBoolean in httpClient.ts, regression test present) and the mtls-client.key VSIX exclusion.

The problem is what the audit certifies as clean. This entry is the designated checkpoint for OC-050 security, and it reads as a clean bill of health while a real vulnerability sits unflagged in exactly the surface it claims to have reviewed:

• (medium) The supervisor report (AGENT_PROGRESS.md:102-108, added by this PR) lists the only OC-050 findings fixed as the inherited-boolean and packaging items, and presents auth/transport/redirects as sanity-checked with no caveat. But _buildRedirectRequest (src/services/httpClient.ts:596-609, unchanged on the base) forwards all headers including Authorization to cross-origin redirect targets, and on 307/308 the request body too (see [15/36] Add OC-050 auth and transport support #49). README's own definition of done requires negative/security-sensitive redirect tests, and none exist. A reader trusting this row would believe the redirect surface was checked. It was not.

The narrative counts here (41/41 demo files) are accurate for this PR, so that earlier concern does not apply to #50 itself.

Verdict: changes-needed. Correct the ledger entry to record the cross-origin redirect header-stripping gap and its missing test coverage as an open risk, or link a follow-up issue, so landing decisions are not made on a false completeness signal. The code fix belongs on #49.

[cjohnsto-nz]

Reviewed. No PR50 change is required.

The re-review correctly identifies a gap in the audit as it existed when the report was written, but its requested remediation is to record an open risk or link a follow-up. That risk is no longer open:

• The code fix belongs to PR49 and is now present there in f97c1c6d5aedd83d8874b2cfc850823c7d6bcb71.
• PR49 now strips standard and configured authentication credentials on cross-origin redirects, redacts authentication query values from execution logs, and includes negative cross-origin redirect coverage.
• PR50 merges against the updated PR49 base, so that fix and coverage are part of PR50's effective merge result.

Adding an “open risk” statement to this report now would be factually wrong. The supervisor entry is a timestamped record of the exact compile/test/package/install checks performed at that checkpoint; it does not state that the audit was an exhaustive security certification.

The separate OC-100 silent-edit defect was fixed on its owning later branch, PR52, and the remaining streaming-sequence edit path is fixed on the stack rework branch in 2b50626915aae4c2671fce67f565f8ba5c6a4f38. Rewriting this historical PR50 report is not the correct ownership location for either fix.

Current stack state: PR50 is MERGEABLE/CLEAN, and its immediate child PR63 is also MERGEABLE/CLEAN.

[cjohnsto-nz]

Response to the second review: agreed. The original OC-050 audit row overstated the redirect review.

The code correction belongs to PR #49 and is now on its current head at f97c1c6, with cross-origin credential/query stripping and regression coverage. I corrected the OC-050 ledger on stack-tip PR #72 in b220ecb: it now names PR #49 as the owner, records sensitive query-log redaction and cross-origin stripping explicitly, and points to the composite verification instead of presenting the earlier audit as complete.

I did not rewrite PR #50, because the final documentation correction belongs to the dedicated rework PR and changing this historical checkpoint would create avoidable descendant churn.