You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(engine): an alphabetical tie between same-number notes gates a note nobody ordered #233
palee adopt --auto-chain orders notes inside a directory by numeric prefix, then phase rank, then alphabetically. When two notes carry the same prefix — m/02-a.md and m/02-b.md, or lab-a.md and lab-b.md — the tree declines to choose between them and the filename collation does. That edge was written with depends_on_source: numbered, and numbered gates.
Measured on the current stack tip: a vault of m/02-a.md + m/02-b.md adopts one edge, reported as 1 numbered, and palee plan --json offers only m/02-a.md. Because no v0.5.x command raised topic_mastery before #228, that lock was permanent.
This is the defect PAL-205 contains for enumeration order — a note hidden behind a position nobody asserted — one level lower in the same planner. The CLI already admits it: the warning says "the order between them is alphabetical".
Approach
Split the label from the consequence. A tie-derived edge is written as depends_on_source: tie and tie joins toc in the advisory set, so:
the edge still ranks the note and still takes part in cycle detection;
it never holds a note off the ready list;
an absent or unrecognized label still gates — fail-closed is untouched, advisory status is granted only by exact name.
numberedEdgeCount keeps counting tie edges, because that number answers the honest-refusal question ("did any planner produce an order?"), not the gating question.
Acceptance criteria
A same-number pair writes its edge with depends_on_source: tie, not numbered.
palee plan offers both notes while the first is unmastered.
The dry-run and commit reports name the tie separately: 1 edge(s) written: 0 numbered, 0 toc, 1 tie (advisory).
tie round-trips through the loader and through an old build's parser without being rejected.
A vault whose only edges are ties is not reported as "no chainable order signal".
Unrecognized and absent labels still gate.
Each guard ships with a test that fails when its deciding predicate is reverted.
Verification round - all seven criteria hold at feat/73-tier0-hygiene @ 0d222bf
The tie is labelled, not silently ordered: src/engine/toc-chain.ts:621 writes tie, src/types.ts:500 makes it advisory, src/engine/dependency.ts:771 is the reader, and palee plan offers both notes while the first is unmastered (test/cli-adopt-autochain.test.ts:828,862-867, test/engine-dependency.test.ts:717). The report names it (src/cli/adopt.ts:806-811, one site serving both the dry-run and the commit), it round-trips through the loader (src/storage/loader.ts:247, test/storage-loader.test.ts:274), and a tie-only vault is not reported as "no chainable order signal" (src/engine/toc-chain.ts:708-711 -> src/cli/adopt.ts:616) - verified live in a temp vault printing enabled (strict tier - 1 edge(s) written: 0 numbered, 0 toc, 1 tie (advisory)). Reverting src/types.ts:500's tie entry fails the gating pair, so neither half is decorative.
Why this never closed: the fix was PRs #234 and #236, both merged into test/pal205-gate-hygiene - a non-default base, so their Closes keywords could not fire. #214 carries Closes #233.
One loose end that is not this issue's: planning/invariants.md:73 still documents depends_on_source as numbered|toc and says the field "never affects gating", which this change made false. Tracked in #238.
Activity
Kuldeep2822k commentedon Sep 30, 2026
Verification round - all seven criteria hold at
feat/73-tier0-hygiene@0d222bfThe tie is labelled, not silently ordered:
src/engine/toc-chain.ts:621writestie,src/types.ts:500makes it advisory,src/engine/dependency.ts:771is the reader, andpalee planoffers both notes while the first is unmastered (test/cli-adopt-autochain.test.ts:828,862-867,test/engine-dependency.test.ts:717). The report names it (src/cli/adopt.ts:806-811, one site serving both the dry-run and the commit), it round-trips through the loader (src/storage/loader.ts:247,test/storage-loader.test.ts:274), and a tie-only vault is not reported as "no chainable order signal" (src/engine/toc-chain.ts:708-711->src/cli/adopt.ts:616) - verified live in a temp vault printingenabled (strict tier - 1 edge(s) written: 0 numbered, 0 toc, 1 tie (advisory)). Revertingsrc/types.ts:500'stieentry fails the gating pair, so neither half is decorative.Why this never closed: the fix was PRs #234 and #236, both merged into
test/pal205-gate-hygiene- a non-default base, so theirCloseskeywords could not fire. #214 carriesCloses #233.One loose end that is not this issue's:
planning/invariants.md:73still documentsdepends_on_sourceasnumbered|tocand says the field "never affects gating", which this change made false. Tracked in #238.