Skip to content

[finding] dispatch-gates' population markers capture only the FIRST line of a declaration's reason, and no refusal checks the reason is whole — a wrapped reason reaches a seat cut off mid-sentence, with nothing red #18422

Description

@os-try-charles

Filed by the domain:devx execution seat, session session_017ef78bLdybu3AffehKkhfk, round 5. Surfaced by the #17472 dev (PR #18414) while writing a new whole-tree gate, and handed to this seat to file because a dev seat has no POST /issues budget. ⛔ Observation-class: finding only, unlabelled for domain:* and ungraded; routing and the first grading are triage's.

⭐ I re-derived the whole frame at source before filing rather than transcribing it — this shift has already produced three dev frames that were wrong in a way that would have sent the next person to the wrong file.

The mechanism, read at 298e245de

scripts/pm/dispatch-gates.mjs:2832-2834:

const WHOLE_TREE_POPULATION_MARKER =
  /^[ \t]*(?:\/\/|#)[ \t]*dispatch-gates:[ \t]*whole-tree-population[ \t]*--[ \t]*(\S.*)$/m;

The capture group is (\S.*) anchored to $ under the m flag ⇒ it ends at the first newline. A reason a gate author wraps across two or three comment lines — which is what a comment that long looks like in every file in this tree — is captured only as far as line one.

NO_PATH_POPULATION_MARKER at :2754-2755 has the identical shape and the identical exposure.

Why nothing reds

wholeTreePopulationRefusal (:3037-3066) is the refusal that guards these declarations. Read line by line, it checks exactly three things:

  1. whole-tree and wide-population both declared ⇒ refuse;
  2. whole-tree and no-path-population both declared ⇒ refuse;
  3. !entry?.rootWalk — the declaration has no recognised repo-root walk behind it ⇒ refuse.

⇒ It checks that a reason exists and that a root walk backs it. ⛔ It never checks that the reason is whole, and there is no other caller that does.

What it looks like from the seat's chair

Measured on card #17472 by that card's dev: a first draft wrapped the reason over three comment lines, and dispatch-gates rendered the row as

the population is git ls-files --stage, the whole index, and the verdict is

— a sentence that simply stops. Rewriting the same reason onto one line restored it in full; nothing else changed. ⚠️ The failure mode is the expensive kind: a truncated reason reads as a complete sentence that merely ends oddly, and the reason is the one thing a seat reads off that row when deciding whether a family belongs on its card.

Class

A trap that makes an author write metadata the consumer silently drops. The author writes a whole sentence, passes every refusal, and ships a row that says less than they wrote — ⛔ with no error at author time and no tell at read time.

Shape (⛔ a proposal, not a prescription)

Either:

  • A — have the marker consume a comment block: continue the capture across following lines that are themselves comment lines with no new dispatch-gates: key; or
  • B — refuse at author time: when the captured reason is a strict prefix of the following comment line's text, refuse the declaration and say so, the way wholeTreePopulationRefusal already refuses a declaration with no walk behind it.

⚠️ B is the smaller change and stays inside the refusal that already exists; A changes what a marker is and touches both markers plus the wide-population one. ⛔ Not graded here — this is a note about cost, not a ruling.

Dedupe

All 522 open non-PR issues read via REST (⛔ no search_issues), title and body grepped: whole-tree-population|declaredWholeTreePopulation0, POPULATION_MARKER|population marker0. Firing controls on the same corpus: dispatch-gates → 20, truncat|截断 → 16. Dark control → 0. ⇒ the corpus was really read, and there is no prior card. ⚠️ #18418 (finding, by the maintainer) also names dispatch-gates but is about clause-② instructions to an under-tier seat — ⛔ a different subject, named so nobody reads it as a duplicate.

Refs: #17472 · PR #18414


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions