Assess the #1311 Burn-Down: the Open Count Is 195 and Has Never Fallen, While Every Handoff Reports the 30-Row Default as the Count

[ptr727]

An independent assessment of the #1311 burn-down after three days, asked for because the issue count
appears to keep growing rather than falling. All numbers are read live from this repository on
2026-09-07 at 23:30Z, from a session holding no branch and authoring none of the work it measures.

Answer in one paragraph

The agents are not reading forward blindly. They executed five of #1311's thirteen sub-issues in
three days and cut the issue filing rate by roughly two thirds. But the burn-down has never actually
burned down, and nobody in the chain can see that, because the command every session uses to count
the backlog caps at thirty rows and the sessions have been reporting the cap as the count. The
handoff file has told each successor that the backlog is about thirty issues and shrinking from 148.
It is 195 and has risen every single day since 2026-08-29. Continue, but correct the measurement,
close the work that is done, and force the two decisions that are the only things that can make the
number fall.

Finding 1: the backlog metric is an artifact of a default limit

gh issue list returns thirty rows when no --limit is given. HANDOFF.md's own "Start here" block
runs that command. Both of the last two handoff revisions report a count that is the row count of a
truncated listing rather than the size of the backlog.

Source	Reported open	Actual open
HANDOFF.md, 2026-09-07 afternoon	30	195
HANDOFF.md, 2026-09-07 late evening	32	195

Reproduce it:

gh issue list --repo <owner>/<repo> --state open | wc -l          # 30, always
gh issue list --repo <owner>/<repo> --state open --limit 400 | wc -l   # 195
gh api repos/<owner>/<repo> --jq '.open_issues_count'             # 196, includes the open PR

This is the single most consequential defect in the loop. Every session opened the handoff, read that
the backlog was around thirty against a recorded 148, concluded the plan was working, and picked the
next small item. The correction is not a judgment call, it is a --limit flag, and it belongs in
whatever renders the count.

Finding 2: the count has risen every day, and has never once fallen

Reconstructed from every issue's createdAt and closedAt, so it is the true open count at the end
of each day rather than a sampled one.

Date	Open at end of day	Change
2026-08-29	33
2026-08-31	72	+39 over 2 days
2026-09-02	97	+25 over 2 days
2026-09-03	111	+14
2026-09-04	163	+52
2026-09-05	180	+17
2026-09-06	184	+4
2026-09-07	195	+11

Two readings, and both are true.

The pessimistic one is that the line is monotonic. In nine days the open count went from 33 to 195
and never declined, not on a single day, including the four days after #1311 named the pump and
prescribed the fix.

The optimistic one is that the slope is bending hard. Growth ran at about 19 per day through 2026-08-31
and about 7 per day over the last two days, and 2026-09-06 added four. The #1311 P0 work is visible
in that bend. What it has not done is cross zero.

The 2026-09-04 spike of +52 is not new discovery. It is #1315's triage converting frozen prose
findings into per-unit trackers, which is bookkeeping the plan asked for. That matters for reading the
curve and does not change where it ends.

Finding 3: real structural progress happened, and the board hides it

Five of the thirteen sub-issues shipped between 2026-09-04 and 2026-09-06, and only one of the five is
closed.

Sub-issue	State	Shipped as	Actually done
#1312 stop condition and round budget	OPEN	#1330	Yes, the rule is in local-strict-review "Disposing of Findings" and reads well
#1313 decouple ledger and digest	OPEN	#1328	Yes
#1314 scope bots, bound the Merge Gate	CLOSED	#1329, #1333	Yes
#1315 labels, trackers, decision list	OPEN	#1334 plus 51 trackers	Partly, the label set stopped being applied
#1317 one rule one home	OPEN	#1378, #1382, #1383, #1384	Mechanism plus first carriers
#1318 bind section 4 to checks	OPEN	#1385, #1388, #1390, #1392, #1394, #1395	Substantially

The stop rule that #1312 asked for is committed and is the right shape. It closes on "is an
introduced finding still open" rather than on a count, and it caps a push at two rounds of edits.
That is the pump's off switch and it is installed.

Four of those six issues stay open because a Closes #N on a pull request targeting develop never
registers. GitHub only auto-closes on a merge to the default branch. So the board reports thirteen of
thirteen sub-issues outstanding when five are done, which inflates the very number this issue is about
and makes the plan look stalled when it is not.

Finding 4: the work drifted off the plan on 2026-09-07

Eleven pull requests merged on 2026-09-07. None of them is a #1311 sub-issue. They are #1409, #1414,
#1417, #1423, #1427 and #1430, plus promotions and Dependabot bumps. Each is sound work and #1423 in
particular is a genuinely valuable tool. But the day filed 24 issues and closed 13, and the plan that
exists to stop the filing was not touched.

This is the closest thing to the rut the question asks about. It is not blind repetition. It is a
session picking the next tractable item off a handoff that told it the backlog was fine.

The mix of what is being filed has improved, which is worth saying plainly. Of the ten issues filed on
2026-09-07, seven are script, gate or tooling defects found by something actually failing in use, which
is exactly the class #1311 said carries the fleet's rigor and said to work first. The corpus is
producing better issues than it was a week ago.

Finding 5: two structural liabilities are untouched, and both are decisions

185 canonical units have never been read here. canonical_review.py report says 298 units, 112
covered, 185 never. #1311 recorded 87 covered and 217 never on 2026-09-04, so three days of work
covered 25 units. At that rate the remaining 185 take about three more weeks, and every first read
historically returns between five and thirteen findings. That is a committed future of several hundred
findings, and it is the reason the curve cannot cross zero on the current plan. Nothing in the shipped
P0 work reduces it.

51 tracker issues have no closing mechanism, and none has ever been closed. The trackers are
correct as a container. #1322 is what empties them, one unit rewritten per pull request, and #1322 has
no pull request and no branch. So a quarter of the open backlog is structurally frozen until #1322
starts.

Both dead ends run through the two items that need Pieter rather than an agent:

• P2 (decision): Carry Only the Fleet Bootstrap Verbatim, and Reach Everything Else From the Hub #1321, carry only the Fleet Bootstrap verbatim and reach everything else from the hub. This is
  the only item on the list that shrinks the corpus instead of reorganising it. It cuts the unit count,
  it removes the downstream re-discovery of the same defects, and it makes a wording change stop being
  a fleet-wide change. It is marked a decision and has been waiting three days.
• P2: Rewrite GOVERNANCE.md and the Review-Loop Skills Into the Normative Format, One Unit Per Pull Request #1322, rewrite each unit into the normative format. Gated on P1: Define the Normative-Statement Format, Lint It, and Pilot It on "Verification Discipline" #1316 and P1: Give Every Rule One Home, Replacing Restatements With Pointers or Generated Includes #1317, and it is what
  closes the 51 trackers.

Neither has been started, and no agent can start #1321 without an answer.

Finding 6: the handoff mechanism is right, the file is not

AGENTS.md "Session Scope" says to hand off in at most 2 KB naming the branch, the pull request, what
is done, and the next command. HANDOFF.md is 12 KB and has grown into a narrative state document
carrying eight ranked next items, eight recorded decisions, an environment note and a mechanics
section.

Keep handing off in a file. It is the correct pattern and the alternative is worse. But this file
violates the rule it is written under by six times, and the length is not harmless: the one number in
it that decides whether the plan is working is wrong, and it is wrong in a document long enough that
nobody re-derives it. Durable content in it belongs in issues, which the file's own opening line
already says.

Recommendation

Do not stop the work. The diagnosis in #1311 is sound, the P0 fixes are real and installed, and the
filing rate genuinely bent. Stopping now would discard that.

Do change four things, in this order.

1. Fix the count before anything else. Every place that reports a backlog size passes an explicit
   --limit or reads search/issues .total_count. Rewrite HANDOFF.md's "Start here" accordingly and
   correct the "32 open issues" line to 195. This is a five-minute change that restores every
   subsequent session's ability to tell whether it is winning.
2. Close what is done. P0: Commit a Stop Condition and Round Budget for the Whole-Unit and Local Review Passes #1312, P0: Decouple the Review Ledger and the Skills Digest From the Working Tree #1313, P1: Give Every Rule One Home, Replacing Restatements With Pointers or Generated Includes #1317 and P1: Bind Every WORKFLOW.md Section 4 Guarantee to an Audit Check, or Mark It Guidance #1318 are shipped and open. Close them against
   their merged pull requests, with the promotion SHA cited, so the board shows five of thirteen rather
   than one of thirteen.
3. Answer P2 (decision): Carry Only the Fleet Bootstrap Verbatim, and Reach Everything Else From the Hub #1321. It is the only lever that shrinks the corpus rather than reorganising it, it
   gates the 185 unread units and, through P2: Rewrite GOVERNANCE.md and the Review-Loop Skills Into the Normative Format, One Unit Per Pull Request #1322, the 51 trackers, and no agent can move it. If the
   answer is no, say so and the 185 first reads become a scheduled cost to be budgeted rather than an
   open-ended one.
4. Cap the opportunistic lane. The 2026-09-07 pattern of picking the next small defect is what
   quietly replaced the plan. Bound it, for example to one item per session, with the rest of the
   session on the numbered sub-issue list, until filed drops below closed for two consecutive days.

The metric to watch is the one #1311 already named and #1324 asks for, and it needs no new machinery
to start: open count at end of day, filed against closed. It has never fallen. The plan is working
when it does.

Related

#1311 (the plan), #1312, #1313, #1315, #1317, #1318 (shipped, still open), #1321 and #1322 (blocked on
a decision), #1324 (the metric this issue computes by hand), #1400 (a second stale-state read in the
same handoff).

[ptr727]

Pieter's decisions, 2026-09-07

Answered directly, so nobody re-asks and nobody re-derives them from prose.

1. Continue the work, with this issue's four corrections applied in order. Do not halt and do not
   re-rank the whole backlog first. The filing rate genuinely bent and stopping discards that.
2. P2 (decision): Carry Only the Fleet Bootstrap Verbatim, and Reach Everything Else From the Hub #1321 gets answered now, in a dedicated session of its own. It is the top priority above the
   opportunistic defect lane, because it is the only item that shrinks the corpus rather than
   reorganising it, and the 185 unread units and the 51 trackers are both frozen behind it.

Correction 1 is applied: HANDOFF.md's "Start here" block now passes an explicit --limit and its
state line reads the true count. The remaining corrections are 2 (close what is shipped, after
checking each against its own acceptance test rather than against a merged pull request alone), and 4
(cap the opportunistic lane to one item per session until filed drops below closed for two
consecutive days).

On correction 2, two of the four are not safe to close blind. #1312 and #1313 look complete against
their scope. #1317 landed its mechanism and its first carriers only, and #1318 is substantial
rather than finished, so each needs its acceptance test read before it is closed. Closing a sub-issue
that is partly done would recreate exactly the false picture this issue is about.