TRACKING: work plan 2026-07-29 — merge the run-1 PRs, fix the severity-1 defects, then run 2 against meta

[mmcky]

Resuming the 2026-07-28 session, which took /audit:issues from "possibly over-complicated" to validated-once-with-seven-defects. Four PRs merged into audit 0.1.2 (#17, #18, #19, #20), run 1 executed against action-translation, and two more PRs are open awaiting review. Program state is in #16; defects in #21.

Blocks are ordered by dependency, not by size. Block 3 before block 4 is the one ordering that actually matters — the reasoning is there.

Block 1 — merge what is waiting (first, unblocks everything else)

• Reviews: run 1 of the audit validation program (action-translation, 2026-07-28) #22 — the run-1 record (reviews/audit-run-action-translation-2026-07-28.md). MERGEABLE / CLEAN.
• audit: re-derive doctrine §4 from evidence the first run actually produced #24 — doctrine §4 re-derived from measured evidence, audit 0.1.3. MERGEABLE / CLEAN.
• Reviews: record the wald_friedman triage run (first no-candidate evaluation) #15 — the wald_friedman triage record. Pre-existing and unrelated to yesterday; GitHub reports mergeable=UNKNOWN, so it may want a rebase.

Merge #22 before or with #24. Three documents in #24 cite the run record by absolute URL, and those links 404 until #22 lands. Either order works if they go in the same sitting; #24 alone leaves a brief dead link.

Block 2 — the judgement only you can supply

• Checks 9 and 10 on the run-1 bundle: does the tiering in 01-issue-triage-report.md match what .dev/PLAN.md actually says, and would you act on it? Both are marked pending in Reviews: run 1 of the audit validation program (action-translation, 2026-07-28) #22 rather than answered, so it merges honestly as-is — append afterwards, or comment on TESTING: validation program for /audit:issues — run it before generalising the method #16.
• Decide the bundle's fate. It is in ~/work/quantecon/action-translation/.dev/scratch/audit-2026-07-28/ — gitignored, so it survives but cannot be committed where it sits. Options: move it to .dev/audits/2026-07-28-issues/ now (pre-empting the convention), or leave it pending QuantEcon/QuantEcon.manual#140.
• Two findings in that bundle are time-sensitive and belong to action-translation, not to this repo: PR #225 is open, mergeable, and measured in #227 to regress the path it touches (93.3% → 33.3%, p = 0.002) — the audit recommends a hold, and the drafted comment is unsent. PR #69 has been open since June and re-creates a directory that Wave 1 deliberately deleted.

Block 3 — the two severity-1 defects (#21)

• Defect 1 — [verified] citations are not checked for reachability. doctrine §2 requires file:line, a merged PR, or a tag, but never that a cited commit be an ancestor of the ref the audit names. Run 1's headline finding cited a commit that exists only on an unmerged branch. Fix: state the requirement in §2, and have the skill run git merge-base --is-ancestor <sha> <ref> before tagging a commit citation.
• Defect 2 — the closed side is never checkpointed. findings.md held the 56 open issues; the 62 closed ones went straight to the catalog. Fix: phase 2 appends both state blocks, and the resume rule reads state from issues.json rather than assuming one block.

Worth one PR — both concern whether an audit's own record can be trusted.

Block 4 — run 2, and why it comes after block 3

• gh auth refresh -s read:project first. The current token has gist, read:org, repo, workflow, write:packages — no read:project, which was run 1's single conclusion-changing gap.
• Run 2 against QuantEcon/meta (161 open / 319 items, ~39 min estimated). Per TESTING: validation program for /audit:issues — run it before generalising the method #16's matrix it is the sharpest test of what generalises: org-wide issues with no code to verify against, which directly stresses doctrine rule 1 and may reveal that [verified] means little for a decision record.
• Interrupt it deliberately around 20–30 findings and restart (tutorial step 4). Run 1 went straight through, so resumability — the claim this whole program exists to check — is still unvalidated.

Why block 3 first: run 2's headline purpose is testing resume, and defect 2 means the checkpoint currently covers only half of phase 2. Testing a resume path against a checkpoint already known to be incomplete wastes the most informative run in the matrix. Fix, then test the fixed version.

Run 2 also produces the second data point that #23 (does the phase apparatus need to shrink?) is explicitly waiting for.

Parallel — no dependencies, any time

• TESTING: audit run 1 on action-translation — seven plugin defects, and a cost claim off by an order of magnitude #21 defects 5, 6, 7 — bundle provenance links point at a machine-local plugin cache; fetch_tracker.py preflight does not check token scopes; one location over-claimed in a summary. All small and independent.
• The benchmark thread was not touched yesterday. PLAN: evaluation rubric v2 — enforce couplings, verdict vocabulary, instrument fixes (from the three-way design review) #7 (rubric v2 design calls), TESTING: review + expert-parallel protocol for the benchmark skill (@xuanguang-li) #10 (Kenko's review — he replied 2026-07-24, and the previous session notes wrongly recorded this as still awaiting response), TESTING: benchmark triage run on wald_friedman — five plugin gaps, and a floor that measures the wrong quantity #14 (wald_friedman gaps).
• Decide on the NEXT-SESSION.md exposure. It was committed to a public branch on 2026-07-28 and force-pushed out; orphaned commit d5f3205 remains reachable, and PR audit: resolve the read-only/working-directory contradiction, and a tutorial for running one #19's timeline links to it. No credentials, but it contains correspondence. Purging needs GitHub Support.

Explicitly not doing yet

• Does the phase apparatus need to shrink? (option B, deferred to run 2) #23 — shrinking the phase apparatus. Deferred to after run 2 by design. One measurement cannot distinguish "over-built" from "easy repo".
• The /audit:prs, /audit:tech-debt, /audit:translations skills (PLAN: audit — from /audit:issues to the bulk-audit family #12). The whole point of the validation program is to prove the shared method before more skills are built on it.