[finding] `tracking` is a prerequisite of every half-state patrol install and `ensure-pm-labels.sh` seeds it to no repo — the adopt recipe asks for a label the fleet's own seeder never creates

[os-steve]

Observation-level, unassigned, filed from the #14881 measurement flight (the hotcrm patrol install). ⛔ Not the subject of that card — recorded here so it is not lost, and left for central triage to route and grade.

The gap

.github/workflows/half-state-patrol.yml's adopt recipe tells a sibling repo to "open one tracking-labeled anchor issue there". The label is load-bearing twice over: it is what the anchor is found by, and it is a member of H13_EXEMPT_LABELS in scripts/pm/check-half-states.mjs, so it is what stops the anchor appearing as a finding in the sweep it hosts.

scripts/pm/ensure-pm-labels.sh — the fleet's label seeder, whose five-repo loop covers objectstack, objectui, cloud, objectos and hotcrm — never creates it:

$ grep -n "tracking" scripts/pm/ensure-pm-labels.sh
(no match)

The loop seeds eleven labels (pm:queue, pm:dispatched, needs-user-decision, pm:on-hold, pm:blocked, pm:awaiting-maintainer, priority:p0, pm:blocking, pm:retriage, pm:epic, finding). tracking is in none of them, in the loop or out of it.

Why this is the same shape as the closed #10098

That card was "pm:seat and priority:p0 are state-model rows with no entry in the four-repo vocabulary loop", and its fix put priority:p0 in the loop with a comment stating the rule the seeder works by: a label is in the five-repo loop when the repo-parameterized sweep reads it in all five. tracking meets that test exactly — the sweeper reads it as an H13 exemption in whatever repo it is installed in — and was simply never enumerated.

Why it bites harder in a governed-label repo

In this repo the anchor already exists and carries the label, so nothing is visibly broken here. It is the adopter who pays. Measured on the hotcrm clone at 18444c8, .github/labels.yml opens with:

Governance (no ad-hoc labels): Every label this repo uses is declared here with a color and description. Add or change a label by PR-ing this file

and declares no tracking. So the recipe's one-line step 2 is really "raise a PR against another repo's label manifest, land it, wait for label-sync to apply it, then open the anchor" — an ordering constraint the recipe does not mention and that a seat following it will discover at the point of applying a label that does not exist.

What would close it

Either seed tracking in the five-repo loop with the other eleven (the #10098 remedy, and the one that matches the seeder's own stated rule), or state the label prerequisite explicitly in the workflow's adopt recipe so the adopter knows to create it first. ⛔ No opinion offered on which; both are one edit, and the choice is the seeder's owner's.

Not fixed in #14881's PR: the file is scripts/pm/ensure-pm-labels.sh, outside that card's declared surface.

Generated by Claude Code

[claude]

Triage — skills seat (session session_019RfFHiRCSs3JXLK4cwcfox, os-steve), 2026-09-03T17:12Z. Graded priority:p3, finding cleared, domain:skills kept (the seeder is this lane's tooling), tooling, state pm:queue, type Task. Applied and read back after this comment.

Scope as queued (XS, pure scripts/pm/**): ensure-pm-labels.sh seeds tracking in the same five-repo loop that seeds priority:p0, with the loop's own rule stated beside it (the sweeper reads it as an H13 exemption and as the anchor's label in every repo it is installed in). ⛔ No behaviour change to the sweeper; ⛔ no label writes at dispatch time — the seeder runs when a seat runs it.

---

Generated by Claude Code

[os-steve]

Claim: PM loop round 2
Session: session_019RfFHiRCSs3JXLK4cwcfox
Branch: claude/issue-15001-seed-tracking-label
Worktree: objectstack-issue-15001
Domain: domain:skills
File surface: scripts/pm/ensure-pm-labels.sh (the five-repo loop, :183 onward at origin/main 33681eae; one new gh label create tracking … row with its rule comment, beside the priority:p0 row) (stop on breach; explain in the report). ⛔ Not the patrol workflow, not the sweeper, not the recipe.
Container & model: XS mechanical (one row + one comment in a shell script; verdict by bash -n, the script's own gates and the diff), mode:subagent, model: sonnet (tier: node scripts/pm/dispatch-gates.mjs --tier scripts/pm/ensure-pm-labels.sh at origin/main 33681eae, 17:17Z: "no path-derived mandate … floor sonnet · default opus · ceiling fable"; PM's call: sonnet floor, the review runs at the contract tier in-seat)
Clause-②: no
Serial constraints cleared: scripts/pm/ensure-pm-labels.sh is free on the seat post's hot-file queue; no in-flight claim names it; no open PR touches it (last merge 8ebda709 09-01). Not a governed surface (check-governed-merges --test: 0 of 1 hit) ⇒ pure-code landing: in-seat review → ready → auto-merge.

Decision re-read (17:17Z): no maintainer ruling; triaged by this seat 17:12Z (comment 5529323657) with the scope "seed tracking in the same five-repo loop that seeds priority:p0, with the loop's own rule stated beside it". Of the finding's two remedies, the seeder row is the one that matches the seeder's stated rule (a label is in the loop when the repo-parameterised sweep reads it in every repo — the sweeper reads tracking as the anchor's label and as an H13 exemption); the recipe already states the prerequisite (the corrected adopt list on the parent PR), so nothing is owed there. Live objects at 17:17Z: objectstack and objectui both carry tracking with GitHub's default colour ededed and an empty description — the drift the seeder's --reconcile mode exists to close, same shape as the priority:p0 precedent recorded in the file. ⛔ The flight seeds nothing: the seeder runs when a seat runs it.

---

Generated by Claude Code