Roadmap — where the work has got to¶

Updated 2026-07-29.

This page carries status only. What each phase is, what it depends on and what "done" means all live in the delivery plan, which is a dated design record and deliberately does not track progress — a spec that changes every week stops being a record of what was decided.

One fact, one home: if a phase's meaning is wrong, fix the plan; if its status is wrong, fix this page.

Key¶

Track 0 — groundwork¶

Delivery phases¶

What is actually next¶

2c.2 needs a human, and deliberately so. Expected citations cannot be derived from what the benchmark models cited: recall@k asks whether the right passage is in the top k, and ground truth taken from what a model cited when handed the top 8 is inside the top 8 by construction — recall would read ~100% however bad retrieval was, grading the retriever against its own output.

test/corpus/citation-shortlist.draft.yaml makes the authoring tractable: 25 ranked candidates per answerable question, to keep or replace. A question whose answer is not in the pool is the most valuable row in the file, being a recall failure the current metric cannot see.

2c.1's result is withdrawn, and the metric it used is exhausted. The original finding — deeper retrieval gaining two code answers — came from a harness that never set Config.Stateless, so every call carried every call before it and a question could be answered from an earlier question's passages. Re-run clean on the v0.1.0 index, limit 8 → 50 converts nothing, and the docs band answers 20 of 20 at limit 8. A boolean that is saturated cannot measure anything.

Sub-question decomposition can. Three independent models (gpt-5.5, gpt-5.6-sol, gpt-5.6-luna), each judging every question separately, agreed on 31 of 36 and found four questions answered INCOMPLETELY — with the missing passages at ranks 10, 14, 21 and 24. Limit 25 would close all four; limit 8 closes none. That is the reranker signal, and it was invisible to answered/declined.

Raising answer.DefaultLimit is nonetheless blocked on #3: at limit 50 the composer declined a question whose premise the passages refute, stating the correct answer inside the decline reason. Trading a completeness gain for a correctness loss is not an improvement, and the current metric would show neither.

4a is delivered. forge v0.9.2 and forge-gitlab v0.6.4 ship the issue capabilities, split into Issues and IssueFiler so a read-only deployment can decline the write path structurally rather than discovering the limit on its first attempt to file. Nothing is needed here to consume them.

4b should follow #3, not precede it. Escalation turns a decline into a filed GitLab issue. A composer that misfiles a refutation as a decline would file tickets asking for documentation that already exists and was already retrieved — the exact noise R-ESC-5's provenance labelling exists to keep out of the tracker.

Approved but unscheduled¶

Carried risks and chores¶

These are not phases and will not surface anywhere else.