The gather's fail-closed enumeration has drifted from the gather in four consecutive rounds — it restates a list that lives elsewhere

[topij]

Logged rather than fixed, under a bound declared before the round that found it.
PR #247 merged with this open.

The immediate finding

session-start's gather preamble states a fail-closed rule and then enumerates
which sources it governs, in three buckets: has a render slot (PR list, cron/CI,
config-drift), carries the rule inline (tracker), excluded with a stated reason
(the two narrative-file reads).

That is 6 of the 7 gather bullets. git status --short /
git branch --show-current — the first bullet in the list — appears in none of
them. Not covered, not excluded, not mentioned. The narrative reads got an explicit
one-sentence rationale for their exclusion; this got silence.

It matters on the paragraph's own terms: the rule names "a missing binary" as one
of three failure causes, and a failed git status renders identically to a clean
tree.

Secondary, LOW: the enumeration says three sources "each have a slot in Render the
briefing", which reads as uniform treatment. PR-list and cron/CI have literal
<… | unavailable: reason> alternations inside the fenced template; config-drift's
is a prose bullet below the template pointing at where the line would go. The
claim is true, the parallelism is not.

The pattern, which is the reason this is an issue and not a patch

Four review rounds on this one paragraph, and every round found the scope
sentence claiming more than the implementation delivered:

round	the sentence said	what was actually true
1	the PR and tracker sources "differ only in that one said so"	CI/cron, in the same rendered line, had the same fail-open untouched
2	"applies to every source below", naming no drift	config-drift's render note was byte-identical to base
3 (author, pre-push)	all four named sources "each have a slot"	the tracker has none; it carries the rule inline
4	a three-bucket enumeration of the sources	omits git status entirely

Each fix corrected the previous sentence and wrote a new one that was also wrong.
That is not four typos. An enumeration that restates a list living elsewhere in
the same document will drift from it, and this paragraph restates the gather's
bullet list from six paragraphs above.

Round 4's version is the most checkable so far — it can be verified by grep, and
that verification is what caught round 3's error before it shipped. But
checkability is not the same as staying true: the gather can gain a bullet
tomorrow and nothing fails.

Directions, none of them obviously right

• Drop the enumeration. State the rule once and let each source's own bullet
  say whether and how it reports a gap. Removes the thing that keeps drifting,
  at the cost of the reader having to assemble the picture.
• Move the rule to the bullets. One clause per gather source, no central list.
  Most robust, most repetitive.
• Make it derivable. The gather is a list and the render template is a list;
  a check could assert every gather bullet is accounted for. This is the only
  option that would actually fail when the two drift — and the reason it is
  attractive is that nothing in this repo tests any workflow doc's prose today.
  It is also the largest.

What is true of all three

There is no behavioural coverage of this file's meaning. Four independent lenses
mutation-tested it across these rounds — reverting the paragraph, inverting its
opening sentence, restoring the old render line — and every mutation SURVIVED at
720 passed, 1 deselected. The panel is the only check this document gets, which
is why four rounds on a nine-line diff each found something real rather than
diminishing.

Related: #245 (a different paragraph of this same step, withdrawn after both
lenses returned HIGH), #231 (withdraw rather than patch), #243 (the four
workflows with no shared doc at all — the same drift risk, one level up).

[topij]

Occurrence data, from the ninth friction-log sweep (PR #257) — the same day, and after this issue was filed.

Two more claims about work already done were wrong, and both were about position, inside sentences that cite #224 for the position problem:

1. The graduation marker and archive preamble first said "four" sections sat below the previous marker. It is three (holding eleven of the fifteen entries — that count was right). Caught by re-counting before the PR existed; corrected on all three surfaces it had reached.
2. The archive preamble said "The first is the eighth sweep's graduation marker". It is third — grep -n '^### ' puts it at line 62, behind two newer sections. Caught by the correctness lens of a fallback panel, not by the author, and logged to The friction log states a positional graduation invariant it does not maintain — new entries land above the marker, so un-graduated content sits on both sides #224 rather than fixed.

What this adds beyond a tally

The mechanism in both is the one this issue names: an enumeration restating a structure that lives elsewhere drifts from it. But there is a sharper version here.

The preamble's previous-sweep ancestor said "the session blocks that accumulated after it" — true then. This sweep changed after → around, correctly, because entries now sit on both sides. The author edited the clause whose breakage was visible and left The first is standing one heading further away. So:

A positional assumption survived prose that was being edited specifically to remove positional assumptions. Not a missed edit — a partial one, where the visible half was repaired and the half needing a grep was not.

That is evidence for this issue's third candidate direction over the other two: the durable move is not writing the enumeration more carefully, it is not restating the structure in prose at all when a command can produce it. Both defects here would have been impossible had the sentence said "see the headings below" instead of asserting their order.

[topij]

Occurrence from PR #260, found by the adversarial panel lens. A citation that named the wrong issue, in a commit message and a PR body.

7ca5ccd's commit message and #260's body both wrote:

Nesting confirmed by rendering the edited section through CommonMark (markdown-it-py), per the method #212 settled on.

#212 is not that. Its subject is "Two lenses read the same sentence oppositely, and the doctrine has no procedure for resolving a factual disagreement" — a procedure for the cockpit to resolve a disagreement between lenses by re-reading the artifact rather than weighing the reports. It says nothing about CommonMark or list nesting.

The trail is visible: the 2026-08-01 handoff block records that disagreement as "Settled by rendering the text through CommonMark" and cites #212 beside it. So the citation was picked up from a sentence where the method and the issue number are adjacent, and the number was carried across as if it owned the method. It does not — it owns the class of problem the method was applied to.

The accurate forms would have been either #116 ("A three-space list continuation is correct CommonMark and silently renumbers under Python-Markdown"), which is the repo's actual precedent for verifying markdown nesting with a real parser, or a citation of #212's rule rather than its instance: resolve a fact by re-running the artifact, not by weighing reports.

Why this belongs here rather than as its own ticket

It is the shape this issue already tracks, at citation granularity: a claim restating something whose owner lives elsewhere, drifting from it. The generalisation the previous occurrences produced — an enumeration restating a list from six paragraphs above will drift from it — holds when the "list" is a single issue number sitting next to a method in an older record.

It also sharpens the direction this issue already favours. "Stop restating the structure" has an analogue for citations: a bare #N beside a claim restates an issue's subject from memory. Naming what the issue says, in the same breath, is what makes the drift visible at writing time rather than at review time.

Disposition

Logged, not fixed, per fallback-review-panel.md's record-prose rule — the lens marked it LOW–MED imprecision, and it appears in no shipped file (grep -n 212 docs/agentic-dev-kit/workflows/session-start.md → no hits), only in narrative. #260's PR body is corrected in place, since editing it costs no commit. The commit message is immutable and stands wrong; this comment is its artifact.