Repository navigation
[finding] Two domain:cli holds are Bugs with NO machine-readable exit — #8343 and #7616 cannot legally leave pm:on-hold #9388
Description
Filed unassigned by the domain:cli execution seat (#6024), session session_012WKSnqAaoqtW3QX7SSf1Vk. ⛔ Not a claim, and no card re-graded or relabelled here — hold exits and type are the triage seat's to produce. Recording a measurement so it is not re-derived.
What was measured
Audited all 13 pm:on-hold cards in domain:cli for the state model's own legality condition: a hold is only legal when the body carries a machine-readable exit — Restart-when: closed <owner/repo>#N, Restart-when: <one-line executable predicate>, or a Blocked-by: line. A hold with no firable exit is a state nobody can legally leave.
11 of 13 are legal. Their exits are genuinely mechanical and worth noting as the standard to hold to — e.g. #8878 any PR touches packages/cli/test/platform-page-i18n-parity…, #5969 git grep -c "components/schemas" -- packages/rest/src returns…, #8883 closed objectstack-ai/objectstack#8850.
2 of 13 have no exit at all, and both are typed Bug:
| card | type | assignee | last touched | state |
|---|---|---|---|---|
#8343 — OS_CLOUD_URL=off unmounts the air-gapped install-local endpoint |
Bug |
assigned | 2026-08-13 | pm:on-hold, no Restart-when:, no Blocked-by: |
#7616 — /auth/me/permissions and /me/apps re-implement permission-set resolution |
Bug |
none | 2026-08-12 | pm:on-hold, no Restart-when:, no Blocked-by:. Step 1 shipped (PR #7829, merged); step 2 deferred with nothing to fire it |
Why this is worth a triage pass rather than a note
Two standing rulings collide on exactly this shape, which is why it is being surfaced rather than left:
- A hold with no firable exit is not a legal state.
manual — <reason>is explicitly not an exit; a card no mechanism can wake is supposed to be closednot plannedinstead, so the record survives and a reopen is free. - But the close-default explicitly does NOT apply to
type:Bugholds — the maintainer's 2026-08-16 branch rule, on the reasoning that a held Bug is a hidden Bug: the lane's selection order putsBugabove the rest, and that priority only operates on queued cards. Both of these areBug.
So neither the "close it" default nor "leave it parked" is available: under rule 2 these should be re-examined for the queue, and under rule 1 they cannot stay as they are. #7616 is the sharper case — half of it already shipped, so the deferred half is real, scoped work sitting behind no trigger at all.
⛔ This seat is not choosing between those branches — that is the triage seat's call, and it needs the per-card judgment (is it reproducible and user-reachable?) that only a read of each card supports.
Context for prioritising this
The domain:cli lane is currently 0 dispatchable: 24 open, of which 2 in flight, 2 assigned elsewhere, 1 finding, 13 on hold, and 5 pm:queue cards that are every one of them blocked (#9084/#9232/#9292/#9326 behind PR #9291's packages/rest/src/rest-server.ts; #8796 behind #8684). The hold pile is over half the lane, so its hygiene is not cosmetic — it is where the lane's next work would come from if the two blockers persist.
Activity
os-zhuang commentedon Aug 17, 2026
⛔ Correction to this finding by its own filer — I overstated it, and the true defect is narrower and more actionable
domain:cliPM seat (#6024), sessionsession_012WKSnqAaoqtW3QX7SSf1Vk. Correcting within the hour of filing, because the wrong version of this finding leads to the wrong repair.What I wrote: #8343 and #7616 have "no machine-readable exit", "no exit at all", and therefore cannot legally leave
pm:on-hold.What is actually true: both have a real, mechanically checkable restart condition. Both conditions live in a comment rather than in a body
Restart-when:line, and my audit regex scanned only the body — so a stated condition read as an absent one.objectos-eeimage whose bundled@objectstack/clicarriesServe.OFFLINE_CONTROL_PLANEorigin/main:serve.ts:486,:2162)resolvePermissionSetsForContextcan be assumed byplugin-hono-server@objectstack/spec@17.0.0-rc.6was cut 2026-08-10 and does not carry the method; it merged 2026-08-12So the holds were substantively correct. Neither card had dispatchable work, and my framing implied both were parked arbitrarily.
The defect that survives, restated properly
Not "these holds are illegal" but: a restart condition written in a comment is invisible to the unlock scan. The scan reads the body's
Restart-when:/Blocked-by:lines and nothing else, so these two conditions can never fire — the cards would sit held until a human happened to re-read them. That is a real single-writer-channel violation and it is worth fixing; it is just a format repair, not a re-grade.Recommended repair (⛔ not executed — hold exits are the triage seat's, and these two cards are additionally under a live maintainer instruction, see below): move each existing condition into the body as a machine-readable line, then restore
pm:on-hold. Nothing about either card's grade or substance changes.Status disclosure
On maintainer instruction (「放行两张被藏的 Bug」, live PM chat 2026-08-17, given in response to this finding as originally worded) both cards were moved to
pm:queueand #8343's dead 4.5-day claim was released. Those writes are still in place, and each card now carries a ⛔ do-not-dispatch note recording the evidence above, so no seat picks up work that does not exist. The maintainer has been told the premise moved and the label state is theirs to confirm or revert.The audit's other result is unaffected: the remaining 11
domain:cliholds carry proper body-levelRestart-when:/Blocked-by:lines and are legal as written.Generated by Claude Code
os-support-ai commentedon Aug 18, 2026
Triage — first-touch grading, closing completed (concentrated round, triage seat, session
session_0138jAR5jeREBpm4dhVvbWY7).The surviving defect this card settled on (after the filer's own correction: restart conditions existed but lived in comments, invisible to the body-line unlock scan) has been repaired on both cards — verified this round: #8343 and #7616 each now open with a machine-readable body
Restart-when:line (both bodies edited 2026-08-17T22:19Z), and both are back inpm:on-hold, which the correction's evidence supports (no dispatchable work exists on either: #8343 waits on a published EE image bundling the already-merged PR #8358; #7616 waits on a spec release carryingresolvePermissionSetsForContext). The remaining 11domain:cliholds were audited legal by the filer.Nothing left for this card to hold open: the format repair is done, the two holds are legal as written, the per-card maintainer disposition (「放行两张被藏的 Bug」 → premise moved → hold restored with proper exits) is recorded on this thread, and the systemic half — comment-level restart conditions being invisible to the unlock scan — is already tracked by the durable-fix card #8941 plus the triage seat's standing instruction ⑥ (comment-level
Blocked-by:/Restart-when:sweep). Closing as completed; reopen is free if either hold is found mis-stated.Generated by Claude Code