AA b17: b16 revision — the non-paper leftovers#

VVN: aa-b17-b16-riskymad-tasks-dv_ClaOp48Max_MMv1r0p0_2026m07d15_16h10
Mode: EDEN (from file, not confirmed — see llog)
Effort: Max per .claude/effort-level
Status: OPEN (3 items)
Origin: the b16 RiskyMAD revision session of 2026m07d15, deferred so that revision could ship.

Important

The b16 paper tasks are NOT here any more.

On 2026m08d04 the six paper-scoped rows (McCoy, Lewis/Tertrais, the public-page sweep, the unsent outreach drafts, the c104 re-pour watch, deprecated tokens in the floor) were moved to the single b16 list of record:

AA b16 — Finalizing the RiskyMAD paper (list of record, lives beside the drafts it plans)hell/mm/b/16/aa-b16-finalizing.rst

They were moved rather than copied, so there is exactly one place to look for b16 work. This entry keeps only the three items that are not about the b16 paper and therefore belong in the site-wide registry under the placement rule (an AA file belongs next to the thing it plans; only larger-than-that-thing tasks live here).

Task list#

k

s

Task

Notes

k3

s2

Reconcile the stale b19 stability claim.

AA b16 says b19 “is at OOv3r0p0” (written 2026m04d27, before the pour); AHA/matheo-floor-pour.md and the HELL filename say PPv1. PPv1 is current; the AA text is stale. A small instance of the same c104 debt.

k2

s1

Fix the ``_``-escaping advice in ``AHA/bibliography-management.md``.

The doc says escape _ as \_ in URLs; testing shows bare _ renders correctly, and the one existing precedent in references.bib leaves it bare while escaping %. Also worth recording there that pybtex-apa-style silently drops url for @techreport / @incollection / @misc, and that the fix is to repeat the URL in a visible note.

k2

s1

Update the assessor registry in ``AHA/vvn-composition.md``.

It lists ClaOp47Max as “current default”. The model has since been Opus 4.8 (ClaOp48Max), Fable 5 (ClaFa50Max), and Opus 5 — for which the 2026m08d03–04 sessions used ClaOp50Max by extension of the ClaFa50Max precedent. All three need LLoL’s confirmation, and the registry should record the rule for forming the next one rather than a snapshot that goes stale each release.

See also#