chore(archive): preserve the external Codex review log + file backlog #166-#170

[KbWen]

Housekeeping, records-only. Clears the oldest open item on the backlog's > 2026-08-09 (wave close + pick order) note — an external reviewer's Codex Work Log left active in work/ — and files five verified defects found while clearing it and the adjacent dependabot backlog. No engine, workflow, validator, or governance-rule change.

Two independent reviews ran before merge and both are adopted; details at the bottom.

1. Archive the external Codex review log

chore-govern-audit-20260808.md → .agentcortex/context/archive/chore-govern-audit-20260808-20260812.md, moved verbatim, with a hash-chained INDEX.jsonl entry.

Archive, not resume. Its terminal state is review | NOT READY → routed back to the PR owner, the correct final state for a read-only reviewer with no local implementation authority. All four of its findings were real and remediated before merge — each fix commit resolved against git before being written into the chain: bec66d4 (look-timing recursion), 691ea68 (fence-blind parser and the PASS-labeled-advisory labels; counted-WARN promotion routed to backlog #103(d)), c1f724b (byte-level LF coverage).

The premise this PR started from was wrong, and the pre-change baseline caught it. The orphan log was not producing a FAIL: the completeness audit is guarded by validate.sh:1548 if has_ship_receipt or 'ship' in gate_set:, so a log without a ship receipt skips it. Baseline pass=118 warn=3 fail=0 skip=2, log not named anywhere in the 165-line run.

The reason that survives is preservation of the first-party artifact. current_state.md:128 already narrates this review in tracked SSoT, so the record was never at risk — the reviewer's own words were, living only in gitignored work/*.md on one machine. Moved verbatim because the log belongs to another owner (codex-root); the closure narrative lives in the INDEX.jsonl decisions field, per the PR #371 precedent.

The archival entry carries no shipped field, because nothing shipped from that log. Verified behaviour-neutral before removing it: log_date = index_dates.get(name) or _filename_date(name) (:291), and an entry only enters index_dates when shipped is a non-empty string (:141-143), so the -20260812 filename suffix supplies the same date. The sibling entry for this PR's own log keeps shipped, because that log did ship.

This PR also archives its own Work Log, per the same #397/#400 precedent it cites.

2. Five backlog rows, each reproduced before being filed

Row	Defect	Priority
#166	TruffleHog AC-5 SHA pin binds the wrapper action, not the scanner binary — and AC-3's "full-history scan" claim is false	P1
#167	validate.sh:2294 destroys the filename inside its own broken-link diagnostic	P3
#168	append_chain_entry.py writes CRLF on Windows into the hash-chained audit log	P3
#169	check_decision_disposition.py is fail-open against off-spec Decisions syntax	P2
#170	Five legacy archived logs publish a personal email — owner decision, not an AI call	P3

#166 is the substantive one. security.yml:101 pins the wrapper action and tests/ci/test_security_workflow.py:211 machine-enforces that pin, but the step passes only extra_args while the wrapper's action.yml declares version: default: "latest" (:21-23), threaded into the docker run image reference (:39, :97). Evidenced by a pre-bump main run — 31288803917 at 44b2e33 (2026-08-09) loads the old action 00155c9d…, then logs version: latest → Digest: sha256:aa821cf4… → "trufflehog_version": "3.96.0". So main, pinned to the v3.95.8 action, was executing a 3.96.0 scanner from a mutable tag. P1 because AC-5's declared object is the scanner version — the bounded blast radius (--since-commit scanning, non-required job) limits the consequence, not the control failure.

All five are filed, not fixed — each fix touches tool, workflow, or .gitattributes code a records-only PR should not carry.

Reviews

Review 1 (different vendor) returned NOT READY with eight inline findings; seven adopted, one partially overruled, each verified against the tree first. It caught three defects in records that become immutable at merge: the shipped overload, a personal email in the Owner field, and — most usefully — that #166's original evidence was invalid, since PR #386's CI runs on the bumped head and therefore shows the new wrapper pulling latest. That claim was re-evidenced from a pre-bump main run rather than withdrawn. It also caught that the Decisions section, written as - **D-N** bullets, was invisible to check_decision_disposition.py (D_ENTRY_RE = ^### D-) — ten decisions carried no disposition marker while the check printed OK. Converted to canonical entries; the checker now reports 12 logs checked where it reported 11. That fail-open became #169. Adjudications are posted per-thread on this PR.

Review 2 (second model tier, prompt stripped of the first review's framing) independently reproduced all four then-existing rows from source — re-fetching the #166 job log and re-implementing the chain hash to recompute all 151 entries — and agreed with every severity. Its three actionable findings are adopted: the stale pick-order note (marked DONE, with the recurrence recorded), the untracked legacy-email disposition (now #170), and this PR's own title and body having gone stale against head — which mattered because the repo squash-merges with them, so merging would have written a false description of these records into main's permanent history. Both earlier passes reviewed the diff; neither reviewed the artifact the merge would produce.

Partially overruled: splitting #166 into its own PR. The line-count argument is weak for a records-only PR whose bulk is one archived log; the independent-origin point is correct and recorded in D-4; the rollback-coupling point was strong because #166 was the shakiest content, and repairing its evidence removed that force. Disagreement recorded rather than resolved silently.

Evidence

• validate.sh and validate.ps1 both pass=118 warn=4 fail=0 skip=2 — exact parity, fail=0. Independently corroborated by review 2 at the same head.
• Isolation by result LINES (repo-gotchas [Feature] Work Log auto-compaction mechanism #14) against the pre-change baseline: three differing lines, of which two are this PR's — INDEX.jsonl referenced logs 147 → 149 and archive size 2110 → 2146KB. The third is a stale-lock WARN from the reviewer's own gitignored artifacts, external to this diff. Not cherry-picked: an intermediate run read pass=100 warn=3 skip=3 while work/ was genuinely empty, and that state no longer holds.
• Chain intact at every rewrite (check_audit_chain.py); the pre-merge tail rewrites correctly recomputed successor prev_sha values, independently confirmed by review 2 recomputing all 151 entries.
• check_decision_disposition.py → OK with 12 logs checked; 11 canonical ### D-N: entries, 11 dispositions.
• test_backlog_validation.py 3 passed at 105 rows; every row at exactly 11 pipes.
• Honest ceilings, stated rather than glossed: the verbatim-move sha256 equality and the 12,276-byte pre-compaction state are both self-attestation no reviewer can falsify — the pre-images were gitignored and are gone. The committed log is 17,110 bytes because it legitimately regrew after archival, where the active-log cap no longer applies. What is checkable, and was: the archived bytes are LF-clean, and the log's Diff Base SHA: 7da1859 resolves to a real 2026-08-08 commit whose current_state.md reads Update Sequence: 143, matching the log's own header.

Rollback: revert this PR. The two archived logs return to untracked state and the chain tail drops two entries.

🤖 Generated with Claude Code

[KbWen]

Independent review at exact head 308627ca4ac98f7a0c8fce5181e17f4dd907aabd: NOT READY.

Own account: this is a records-only change that appends two hash-chain entries, commits two archived Work Logs, and adds three backlog rows. The chain and file references are intact, the focused suite passes (43 tests), and #167/#168 are reproducible. It is not correct or safe to merge as written because the records contain a decision-disposition bypass, a machine-field semantic misrepresentation, an invalid #166 evidence claim, an incomplete #168 remediation, and public PII.

Independent backlog severity: #166 mutable scanner HIGH/P1; #166 full-history claim MEDIUM/P2; #167 LOW/P3; #168 LOW/P3. I disagree with the row only on #166's mutable-image half. Note: the initial PR diff fetch exposed the row priorities before I could preserve the requested blind ordering; these ratings were then derived independently from source and reproduction, not adopted from the rows.

Could not verify: actual main branch-protection required contexts (GitHub API 403); the deleted gitignored pre-image for the verbatim-move hash; the intermediate 12,276-byte active-log state. I verified what remains falsifiable and called out those limits inline.

GitHub does not allow the PR author account to submit REQUEST_CHANGES on its own PR, so this review is posted as COMMENT; the substantive verdict remains NOT READY.

[KbWen]

Adjudication — 8 findings, 7 adopted, 1 partially overruled

Each finding was verified against the tree before acting, not accepted on read. Thank you for the NOT READY; three of these were real defects in records that become immutable at merge.

Adopted in full

[P1] Bullet-form decisions evade the disposition check — confirmed exactly as described. D_ENTRY_RE = re.compile(r"^### D-") (check_decision_disposition.py:80) and the caller's if not entries: continue (:285-288) mean the log was skipped entirely, not passed. Converted all ten to canonical ### D-N: entries with → local dispositions; the checker now reports 12 logs checked where it previously reported 11 — the log went from invisible to actually verified. The fail-open itself is now backlog #169, framed as the #138 Signal-A tripwire failing in the direction it exists to prevent: a green check is worse than no check because it reads as compliance. Preferred fix recorded as (a) WARN when a non-empty, non-none Decisions section yields zero canonical entries, rather than (b) blessing a second dialect.

[P1] shipped overloading — confirmed, and I went further than the suggested remedy. Rather than invent a field no consumer understands, I verified the fallback path first: log_date = index_dates.get(name) or _filename_date(name) (:290), and an entry only enters index_dates when shipped is a non-empty string (:141-143). So omitting the field entirely is behaviour-identical — the -20260812 filename suffix supplies the same date — while making no false claim. Done.

One correction to the finding as filed: it is blanket where the situation is not. The sibling entry for this PR's own Work Log keeps shipped: 2026-08-12, because that log genuinely did ship. Only the retroactive-archival entry drops it.

[P1] The #386 job-log claim is invalid — you are right, and this was the most useful finding. #386's CI runs on the bumped head, so its log shows the new wrapper pulling latest. The claim was re-evidenced rather than withdrawn: main-branch run 31288803917 at 44b2e33 (2026-08-09, pre-bump) loads the old action trufflesecurity/trufflehog@00155c9d…, then logs version: latest → latest: Pulling from trufflesecurity/trufflehog → Digest: sha256:aa821cf4… → "trufflehog_version": "3.96.0". So main was executing a 3.96.0 scanner while pinned to the v3.95.8 action. Row updated with that run and an explicit note about the rejected evidence.

[P1] #166 severity — adopted, P2 → P1. Your reasoning is better than mine: AC-5's declared object is the scanner version, so the blast-radius argument bounds the consequence, not the control failure.

[P2] O_BINARY alone is insufficient — confirmed. .gitattributes carries *.json (:16) but no *.jsonl, so the file falls under * text=auto (:2) and a normal Windows checkout materialises CRLF. My w/lf reading was a post-normalise artifact of one working copy, exactly as you say — not a repository invariant. #168 now requires both halves: the O_BINARY flag and an LF checkout contract (*.jsonl text eol=lf). Your independent reproduction of the migrate() path is cited too; that half was previously flagged as unverified.

[P2] Personal email as Owner — confirmed against the template (<session-id or username>), changed to KbWen. Note for the maintainer rather than this PR: the same address already appears in five older archived logs, which I am surfacing rather than rewriting unilaterally.

[P2] The compaction claim is not established by the committed artifact — confirmed. The file is 17,110 bytes because it legitimately regrew after archival, where the active-log cap no longer applies. The 12,276-byte pre-archive state was gitignored and is gone, so that number is not falsifiable by any reviewer. Stated as an explicit ceiling alongside the sha256 one, rather than left as a bare claim.

[P3] Stale Checkpoint SHA — confirmed, 160acc4 → 33fb21a.

Partially overruled

[P2] Split #166 into its own PR. Three sub-arguments, adjudicated separately.

• Line count. Weak here. Of 369 added lines the large majority is one archived Work Log, which is a record to be preserved rather than logic to be reviewed; the ~100-line guidance targets review effectiveness on changed behaviour.
• Independent origin. Correct, and now recorded in D-4 rather than glossed.
• Rollback coupling. This was the strong form of the argument, and it was strong because [Feature] Deletion-First Norm + ADD-gate signal tiering (governance anti-bloat) #166 was the least-solid content in the PR — which your own P1 finding demonstrated. That finding has since been repaired with a pre-bump main run, making [Feature] Deletion-First Norm + ADD-gate signal tiering (governance anti-bloat) #166 the best-evidenced row in the set. The premise that gave the coupling argument its force no longer holds.

Kept together, with the disagreement recorded in D-4 rather than resolved silently. If the maintainer prefers the split it is a one-command change and I will do it.

On your stated limits

Branch protection, which you could not read (403): required contexts are Framework Validation, ShellCheck, Check Markdown Links, with strict: true. That confirms the #166 row's claim that Secret Detection (TruffleHog) cannot block a merge. The two deleted gitignored pre-images — the verbatim-move hash and the 12,276-byte state — are both now carried as explicit honest ceilings; you are right that neither is reproducible.

Noting the ordering leak you flagged: the row priorities were visible in the diff before you could rate blind. Your independent ratings still moved the outcome (P2 → P1 adopted), so I do not think the leak neutralised the exercise, but it is worth designing around next time.