Five decisions queued by a 10-hour autonomous TEAMLEAD stretch — measured, deliberately not taken #631

Filed by TEAMLEAD, session 15b69750, at the end of a ~10-hour autonomous stretch (operator AFK,
no other pane active). 13 PRs merged, ~35 issue comments, 0 issues closed.

⚠ This is not a friction report and not a capture. Every item below is a decision I deliberately
did not make, having done the measurement that makes it decidable. They exist only scattered
across comment threads, which is the defect #235 §1 and #338 name. Collected once so they are
addressable.

Each is stated as: the measurement · the decision · why it is not mine.

1 · #80 and #253 each carry TWO different close conditions — which bar applies?

#80   BODY     "rules authored … by an author who HAD NOT BEEN BURNED by that shape"
               — #80 itself: "a fact about a person's history, not about an artifact"
      COMMENT 5  three artifact-cited items, each resolvable
#253  BODY     POPULATION/PREDICATE/CHANNEL, and: "⛔ CALLER THAT STILL RUNS IT:
               none exists and I am not claiming one"
      COMMENT 1  four numbered items, each testable

In both, the comment's version is the achievable one and the body's is not. Every scanner here
reads the body. close-mechanism.py scores #80 ACTIONABLE on the strength of a body condition its own
issue calls unmeetable — a live instance of that tool's stated bound ("presence is checkable; quality
is a reading").

⇒ The decision: which condition governs. ⛔ Not mine — picking the easier of two bars on
someone else's issue is not triage, and I noticed the discrepancy rather than authored either.

2 · #173 and #214 — is "annotated unmeetable" an acceptable discharge?

Both now carry, inline at the clause, that it is unmeetable because #327 refuted issue authorship.
#601's box 1 explicitly allows "replaced with a measurable discriminator or annotated as
unmeetable-as-written with #327 cited."

⚠ But the first branch is structurally impossible for these two, and that is measured rather than
assumed:

#268   clause is about COMMITS  → a commit has a PR, a PR has a branch → discriminator EXISTS
                                  (corrected, and it PASSES: 17 selected, 0 missing a trailer)
#173   clause is about ISSUES   → an issue has no branch               → none exists
#214   clause is about an ISSUE/instance author                        → none exists

⇒ The decision: whether those two rest permanently on the annotation branch, or the conditions are
rewritten to ask something else. ⛔ Not mine — rewriting someone's close condition changes what
their issue is for.

3 · #502 C4 — fleet-preflight.sh exits 1 while its own header twice says it never does

:9    "# Exit code is always 0: this pane reports, it does not gate."   ← still there
:236  "⚠ This pane still does not gate: exit code is always 0."         ← still there
:352  [ "$fail" -gt 0 ] && exit 1                                        ← still there

#175 §1 settles the contract: the pane cannot gate, because the recipe carries no ordering or
dependency field, so nothing consumes the exit before all nine panes are up. ⇒ The headers are right
about intent and exit 1 is the defect.

⇒ The decision: remove exit 1, or keep it as a signal to a human reading the pane and fix the
headers instead. ⛔ Not mine — onboard.md makes this pane the acceptance test for an install, so
changing its exit contract changes what "a clean install" means. ⚠ It did not fire today (0 fails),
which is the state that survives longest.

4 · #363 — IGNORED is still not a state distinct from MISSING

"Downstream, docs/ is gitignored, so those three are not merely missing — they are unlandable
at the cited path. Any checker must treat IGNORED as distinct from MISSING, or the fix a reader
reaches for is git add -f, which passes the check and reaches nobody."

check-onboard.py tests existence in this repo: check-ignore/IGNORED occurrences — 0.

⇒ The decision: whether an upstream checker should model a derived estate's ignore rules at all.
⛔ Not mine to settle alone — and I have no derived estate, so I cannot even measure whether it
would fire.

5 · pipe-exit-scan.py --exact — offered under review, deliberately not built

--project is a substring, so -repo also matches -repo2. I kept the substring (this fleet's slug
must reach its per-worktree dirs) and made the ambiguity visible — matched directories are named
with per-dir counts. Verified today that no flag was added: add_argument hits for exact = 0,
and --exact returns VOID.

⇒ The decision: whether naming the dirs is sufficient, or an --exact mode is wanted. ⛔ Left
unbuilt on purpose: speculative flags are how a tool acquires a surface nobody uses.

⇒ Done when

• Each of the five items above has a recorded disposition — a decision taken, or an explicit
  DROPPED, because <reason>.
• ⛔ Silence on an item is neither. An item never mentioned again is indistinguishable from one
  nobody read, which is the failure this issue exists against.

Caller: python3 tools/close-condition-scan.py must read this issue as BODY, and a reader
counts five dispositions in this thread against the five headings above.

⚠ Bound: this lists what I declined, not what I missed. An item I never noticed cannot appear
here, and nothing in this fleet enumerates those.

TEAMLEAD, session 15b69750, 2026-09-07 · every item re-verified at origin/main before filing