Epic: Level 3 · Intermediate recipes #77

Activity

1. CompleteDotTech

   added this to the M3 · Intermediate milestone on Oct 6, 2026
2. CompleteDotTech

   added

   type: epicTracking issue that groups other issuesTracking issue that groups other issues

   level: 3 intermediateMultiple judgments or stages with deterministic compositionMultiple judgments or stages with deterministic composition

   priority: p2Scheduled after p1 workScheduled after p1 work

   on Oct 6, 2026
3. CompleteDotTech

   added sub-issues on Oct 6, 2026

   • Recipe 24: Incident priority composition #24
   • Recipe 25: Change evidence review #25
   • Recipe 26: Prompt-injection screening #26
   • Recipe 27: Function selection #27
   • Recipe 28: Skill selection #28
   • Recipe 29: Tool outcome verification #29
   • Recipe 30: Citation verification #30
   • Recipe 31: Patch risk triage #31
   • Recipe 32: Regression test selection #32
   • Recipe 33: Schema field mapping #33
   • Recipe 34: Evidence relationship labels #34
   • Recipe 35: Semantic feature extraction #35
   • Recipe 36: Card-game action selection #36
   • Recipe 37: Research domain tagging #37
   • Recipe 38: Abstention and review queues #38
   • Recipe 39: Document extraction cascade #39
4. CompleteDotTech

   marked this as blocking on Oct 6, 2026

   • Release 1.0: cross-recipe audit, documentation pass, and tag #73
5. CompleteDotTech

   added a parent issue on Oct 6, 2026

   • Cookbook roadmap: 60 recipes from foundation to release #80
6. CompleteDotTech commented on Oct 13, 2026

   

   CompleteDotTech

   on Oct 13, 2026

   ContributorAuthor

   More actions

   Level 3 complete — recipes 24 to 39 all published

   Every recipe in this epic is merged and on main, verified directly: all sixteen issues (#24-#39) are closed, and recipes/01-… through recipes/39-… all exist on main at 5caf98f. 39 of 60 published, 23 merges. Closing.

   What this wave's recipes cover

   Multiple judgments or stages, structured evidence, deterministic composition, task-level evaluation — and in practice the wave was where the cookbook's checks stopped being sufficient on their own. A few things it established that are worth carrying into Level 4:

   • Composition is where the defects live. The recurring shape was not a wrong number but a true number measuring the wrong thing: a task-level metric crediting candidates a gate had excluded; a pooling order that kept counts right while making the printed attribution wrong; a confidence gate that was mathematically incapable of changing any outcome; a baseline that was provably optimal, so the headline metric could not distinguish any policy from any other. None of these are visible to a numeral check, and all were found by a reviewer deriving the claim at the current numbers.
   • The evidence a check needs is often already being computed. Five times in this wave the value that would have caught a defect was already printed and simply unasserted — a figure count, a run mode, a threshold re-derivation, a request count, a mean score. "Before designing a check, look for the value the code already computes" came out of this wave repeatedly.
   • A check keyed on a source idiom certifies the letter. Several guards match a spelling as a proxy for a property they cannot see, and each has now been shown to pass something it should fail or fail something it should pass. Those are tracked individually: Foundation: four set-wide gaps from the recipe 25 review (queue attribution, threshold binding, forced-metric disclosure, baseline template line) #222, Foundation: the confidence-gate reason-string guard proves a string is present, not that a live review branch produces it #227, Foundation: the validation-metric-line guard keys on formatting idioms, not the printed value (one false negative, two safe false positives) #234, Foundation: nothing pins a notebook's threshold OBJECTIVE — a keyword swap ships a byte-identical notebook with a false printed objective line, all checks green #244, Foundation: three recipe-guard checks skip for a scripted recipe, one of which would FAIL — and the skips are keyed on responses.json rather than on the property each check means #249.

   Known residue, all tracked

   • The inbound-link close-out audit (catalog_audit) fails for 11 of 39 recipes — 28, 30 through 39 — and those failures are visible only to someone who runs a deselected marker by hand. Tracked on Foundation: the wave close-out audit has no procedure that runs it #214, where both the measurement and the scheduling argument have been corrected; the sweep is the natural next piece of recipe-side work now that the wave has closed.
   • Deferred post-approval prose items for several of this wave's recipes are batched in the orchestration notes rather than fixed in place, because fixing them would have voided verified approvals whose carry-forward rested on an empty recipe-path diff.
   • Eighteen foundation issues were filed during this wave, several with validated fixes and measured audits attached.

   Level 4 (#78) is next: thirteen advanced recipes, #40 to #52.
7. CompleteDotTech

   closed this as completedon Oct 13, 2026
8. CompleteDotTech commented on Oct 14, 2026

   

   CompleteDotTech

   on Oct 14, 2026

   ContributorAuthor

   More actions

   Correction to the closing comment above: 28 foundation issues, not eighteen

   My comment closing this epic said "Eighteen foundation issues were filed during this wave". That number was carried from my own running tally rather than measured, and it is wrong.

   Measured, with the criterion stated so it can be rechecked: this wave ran from recipe 24's merge (2026-10-11) to recipe 39's (2026-10-13), and the GitHub search API reports 28 issues labelled type: foundation created on or after that first date.

   is:issue label:"type: foundation" created:>=2026-10-11   ->  total_count 28
   

   The understatement is not flattering in either direction — it undersells how much the wave surfaced, and more importantly it is the kind of figure a later reader would reasonably reuse. Recorded here rather than edited into the original comment, so the mistake and its correction both remain visible.

   How the error happened, which is worth more than the number

   I had also been reporting "30 open foundation issues" for most of this wave. That came from:

   gh issue list --state open --label "type: foundation" --json number -q '.|length'
   

   gh issue list defaults to a limit of 30. So that command returns 30 whenever there are at least 30 — it was reporting its own page size, and the true figure is 36. The same query at --limit 50 gives 36, as does the search API's total_count.

   This is the same failure this repository has spent the wave cataloguing — a mechanical check trusted without establishing that it can produce the answer you are asking for — with one aggravating feature: a default cap of 30 looks exactly like a plausible total. A silent zero invites suspicion; a plausible number does not. I reported it repeatedly without it ever looking wrong.

   For anyone counting issues here: use gh api -X GET search/issues -f q='…' -q '.total_count', or pass an explicit --limit well above the expected count and confirm the result does not equal the limit.