Recall goes blind at every milestone close: the corpus reads only live phase dirs #203

New issue

Closed

opened 2026-08-16 17:22:21 +00:00 by john · 0 comments

john commented

2026-08-16 17:22:21 +00:00

Owner

Reproduced live, one hour after the fact

milestone-prune --mode delete removed .planning/phases/1 and
.planning/phases/2 during today's v3.5.2 close. The recall corpus walker
(cadence-core/bin/planning.mjs:2036-2064) builds its corpus from
phases/<N>/SUMMARY.md, phases/<N>/UAT.md, phases/<N>/CONTEXT.md and
CAPTURE.md, and nothing else.

So, right now, on this repo:

$ node cadence-core/bin/planning.mjs recall "lease grammar containment predicate"
{"ok":true,"results":[{"source":"CAPTURE.md",...},{"source":"CAPTURE.md",...}]}

Zero hits from SUMMARY, UAT or CONTEXT. The LSE-01 decisions, the D-01 through
D-12 numbered decisions, the eight UAT criteria and the phase-2 goal check
shipped a few hours ago are already invisible to recall. Only CAPTURE.md
survives the close, because it is the one corpus file that does not live under
phases/.

Why this is the most serious finding in the review

PROJECT.md's stated Core Value is:

What Cadence writes down during a project (deviations, decisions, captures,
UAT findings) must come back on its own at the moment it matters - planning,
context-gathering, and debugging - without any external memory system.

Three of those four categories live only under phases/<N>/. The close deletes
them from the live tree, and recall reads only the live tree. So the product's
central claim holds for exactly one milestone and then silently stops holding,
with nothing anywhere reporting the loss. The corpus does not degrade over a
project's life, it RESETS at every close.

The --mode archive arm is no better for recall: the dirs move to
_archive-<label>/, which the walker also does not read. And on a tagged
release (--mode delete, the default for a release milestone) git history is
the only remaining copy, which recall does not search either.

Scope note, so this is not overstated

Nothing is LOST. The artifacts are in git, and on an untagged close they are on
disk under _archive-*. This is a recall/reachability defect, not a durability
one. The damage is that automatic cross-milestone learning - the thing that
distinguishes Cadence from a folder of markdown - quietly becomes
single-milestone learning.

Exits, cheapest first

Walk _archive-* too. One-line-ish for the untagged arm; does nothing for
a tagged release, which is the common case here.
Leave a distilled residue at the close. milestone-prune writes the
pruned phases' decisions and deviations into a single
.planning/SHIPPED-<label>.md that the walker reads, the way ## Shipped
already preserves requirement rows for /cad-audit after the dirs are gone.
This is the shape the codebase already chose for the same problem one layer up.
Search git. Correct and complete, and it makes a zero-dep deterministic
BM25 walk depend on shelling out to git with an unbounded corpus. Probably
wrong for this tool.

Option 2 mirrors an existing, working decision and is the recommendation.

Directly undercuts the read-back gate proposed in #190: a gate that asks whether
a planner used prior decisions would be measuring a corpus that empties itself
every milestone. Fixing this is a prerequisite for that being meaningful.

Source: external strict re-review, 2026-08-16 (MEM-01, Medium). Verified live
here rather than taken on the reviewer's word.

## Reproduced live, one hour after the fact `milestone-prune --mode delete` removed `.planning/phases/1` and `.planning/phases/2` during today's `v3.5.2` close. The recall corpus walker (`cadence-core/bin/planning.mjs:2036-2064`) builds its corpus from `phases/<N>/SUMMARY.md`, `phases/<N>/UAT.md`, `phases/<N>/CONTEXT.md` and `CAPTURE.md`, and nothing else. So, right now, on this repo: ``` $ node cadence-core/bin/planning.mjs recall "lease grammar containment predicate" {"ok":true,"results":[{"source":"CAPTURE.md",...},{"source":"CAPTURE.md",...}]} ``` Zero hits from SUMMARY, UAT or CONTEXT. The LSE-01 decisions, the D-01 through D-12 numbered decisions, the eight UAT criteria and the phase-2 goal check shipped a few hours ago are already invisible to recall. Only `CAPTURE.md` survives the close, because it is the one corpus file that does not live under `phases/`. ## Why this is the most serious finding in the review `PROJECT.md`'s stated Core Value is: > What Cadence writes down during a project (deviations, decisions, captures, > UAT findings) must come back on its own at the moment it matters - planning, > context-gathering, and debugging - without any external memory system. Three of those four categories live only under `phases/<N>/`. The close deletes them from the live tree, and recall reads only the live tree. So the product's central claim holds for exactly one milestone and then silently stops holding, with nothing anywhere reporting the loss. The corpus does not degrade over a project's life, it RESETS at every close. The `--mode archive` arm is no better for recall: the dirs move to `_archive-<label>/`, which the walker also does not read. And on a tagged release (`--mode delete`, the default for a release milestone) git history is the only remaining copy, which recall does not search either. ## Scope note, so this is not overstated Nothing is LOST. The artifacts are in git, and on an untagged close they are on disk under `_archive-*`. This is a recall/reachability defect, not a durability one. The damage is that automatic cross-milestone learning - the thing that distinguishes Cadence from a folder of markdown - quietly becomes single-milestone learning. ## Exits, cheapest first 1. **Walk `_archive-*` too.** One-line-ish for the untagged arm; does nothing for a tagged release, which is the common case here. 2. **Leave a distilled residue at the close.** `milestone-prune` writes the pruned phases' decisions and deviations into a single `.planning/SHIPPED-<label>.md` that the walker reads, the way `## Shipped` already preserves requirement rows for `/cad-audit` after the dirs are gone. This is the shape the codebase already chose for the same problem one layer up. 3. **Search git.** Correct and complete, and it makes a zero-dep deterministic BM25 walk depend on shelling out to git with an unbounded corpus. Probably wrong for this tool. Option 2 mirrors an existing, working decision and is the recommendation. ## Related Directly undercuts the read-back gate proposed in #190: a gate that asks whether a planner used prior decisions would be measuring a corpus that empties itself every milestone. Fixing this is a prerequisite for that being meaningful. Source: external strict re-review, 2026-08-16 (MEM-01, Medium). Verified live here rather than taken on the reviewer's word.