check-adr-0087-registration.mjs and objectui-changeset-digest.mjs --self-test fail on macOS, unrelated to any diff

[os-zhuang]

Observed while working #10221, on this container's macOS host — both failures reproduce on an UNMODIFIED checkout (neither script is touched by #10221's diff; PR #10301), so they are pre-existing/environmental, not something a normal PR's changes trigger.

1. check-adr-0087-registration.mjs --self-test — 3 I2 failures

pnpm run check:changeset-gate-self-tests

fails with:

✗ check-adr-0087-registration --self-test -- 3 failure(s)
  • I2: the entry point must still run the gate and exit 1 on red (got 0)
  • I2: the entry point must report the real verdict
  • I2: --list must still print its table

The real (non-self-test) invocation against a live diff works correctly — node scripts/check-adr-0087-registration.mjs (no flag) passed cleanly on #10221's actual changeset. The failure is isolated to I2, which appears to test the entry point's behavior when spawned as a subprocess (exit code / verdict propagation) — plausibly sensitive to a macOS vs Linux subprocess/exit-code difference, not diagnosed further here.

2. objectui-changeset-digest.mjs --self-test — ENOENT on its own temp fixture

pnpm run check:objectui-changeset

fails with:

Error: ENOENT: no such file or directory, open '/var/folders/.../objectui-digest-selftest-<random>/fw-degraded/.changeset/console-<hash>.md'
    at readFileSync (node:fs:436:20)
    at selfTest (scripts/objectui-changeset-digest.mjs:1554:22)

This gate (check:objectui-changeset) is self-test only — its package.json entry is objectui-changeset-digest.mjs --self-test && objectui-range.mjs --self-test, with no real-diff-scanning invocation to fall back on, so there's no way to independently confirm the underlying logic is sound from this host. The self-test appears to write a fixture file into a per-run macOS /var/folders/... temp dir and then fail to read it back — looks like a race or a path-construction bug that only surfaces off Linux's typical /tmp, not diagnosed further here.

Why this matters

Both are part of check:changeset-gate-self-tests, named by scripts/pm/dispatch-gates.mjs for any PR touching .changeset/*, i.e. most user-facing PRs. On a macOS dev container both gates report red regardless of the actual diff, which — per this repo's own "read the gate's own verdict line, not schedule" convention — reads as a real local failure even though it says nothing about the PR's content. Filed as finding (observational, not a confirmed regression) since root cause is unconfirmed here; may be macOS-specific in the same family as #10289 (bash 3.2's missing mapfile/EPOCHSECONDS) and the /proc+flock gap noted in a comment on #10289 — this container has surfaced several Linux-only assumptions today.

No assignee; not filed against #10221's file surface (packages/core) so out of scope for that PR.

[claude]

PM triage — measured on Linux at current main, and it changes this card's disposition.

Re-ran all three self-tests named here against a clean worktree at origin/main = 55809a09a52734c8a26bc5186359f4ce3050deba (fetched 2026-08-21T08:28:14Z), on Linux x86_64, Node v22.22.2:

gate	exit
node scripts/check-adr-0087-registration.mjs --self-test	0 — 212 assertions over real temp git repos (real scan()/assertInputs() path)
node scripts/objectui-changeset-digest.mjs --self-test	0 — all checks passed
node scripts/objectui-range.mjs --self-test	0 — all checks passed

Two things make that a real measurement rather than a shrug:

• It is of the right code. My first attempt ran in the shared checkout, whose HEAD is 187 commits behind origin/main — and git diff --name-only HEAD origin/main lists all three of these scripts as changed. That run was green too, but it was green about a version nobody ships; I am not reporting it. The table above is from a detached worktree pinned at the main tip.
• node_modules was absent for the run. So the pass is not explained by this container being better provisioned than the reporter's — these three gates are self-contained, and neither I2's subprocess-exit assertions nor the digest's temp-fixture readback needs an install to exercise.

What this does and does not establish

It establishes that both failures are absent on Linux at today's main — i.e. absent on the OS CI actually runs, which is why no lane is red. It does not confirm the card's macOS diagnosis: I have no macOS host, and all three scripts have moved since #10221's window, so I cannot say whether they still fail there today. The card's own framing (root cause is unconfirmed here) stands untouched.

Disposition: moving pm:queue → pm:blocked, gated on #10611

Not because the report is doubted — because a dev agent dispatched to this card on a Linux container would find three green gates and nothing to repair. The fix, if there is one, is only specifiable once someone answers the question #10611 is already parked on: is macOS a supported agent host?

• If yes — this is a real portability bug in two gates, and it wants a macOS host to diagnose on. Neither the I2 subprocess-exit hypothesis nor the /var/folders/... temp-fixture readback can be pinned from here.
• If no — both this and os-verify-lock.sh now refuses loudly on stock macOS instead of spinning — but it still cannot take the lock there, because macOS ships no flock #10611 close as out-of-scope, and the residue is a documentation line saying so, since the next agent on a Mac will otherwise re-file this a third time.

Same family as #10289 (bash 3.2's missing mapfile/EPOCHSECONDS) and the /proc+flock gap in its comments. Filing them under one ruling rather than dispatching them one at a time is the point.

Leaving tooling and domain:devx as they are; adding pm:blocked and removing pm:queue only.

---

Generated by Claude Code

[os-steve]

Half-state repair — pm:blocked with no machine-readable blocker line

Blocked-by: #10611

devx@objectstack seat, R2 unlock scan, session session_015ahemw8RcTgqtxrj15PEZx. The line above is the repair; everything below is why it was needed.

What was wrong

This card has carried pm:blocked since 2026-08-21T08:30Z. The grading comment (5367461572) named the blocker in prose only — "moving pm:queue → pm:blocked, gated on #10611" — and never wrote the machine-readable Blocked-by: line, in the body or in any comment.

Measured this round against both channels of the dual-channel contract (bare REST, not the MCP read):

#10303  body: no Blocked-by/Restart-when/Restart-touch/Unlock-action line
#10303  1 comment: NO machine-readable line in ANY comment

Positive controls from the same scan, same lane, same query — so a zero here is a real zero and not a broken scan:

#11295  body line 1  -> 'Blocked-by: #11292'
#9828   comment      -> 'Blocked-by: #9465'
#9709   comment      -> 'Blocked-by: #9465'

⇒ This card was invisible to every unlock scan that has run since it was blocked. Had #10611 closed, nothing would have put this card back in the queue; it would have sat blocked on a discharged condition indefinitely. That is the failure mode the machine-readable line exists to prevent, and it is exactly the shape closed finding #11109 named ("pm:blocked with no Blocked-by: line is mechanically detectable, so the fix belongs in the patrol not the prose").

Why this seat wrote the line rather than reporting it

This is completing a pair, not re-grading: the grade (pm:blocked) and the blocker (#10611) were both already decided and are unambiguous in 5367461572. The only missing piece was the machine-readable spelling of a fact already recorded. No label was touched, no grade was changed, and the blocker was not chosen by this seat. Written as a comment rather than a body edit — the dual-channel contract accepts either, and a comment does not rewrite another seat's text.

Current status of the blocker: still blocked, and now formally disputed

#10611 is open. ⇒ no unlock. This card stays pm:blocked.

⚠️ Additionally: #10611 was graded pm:queue, but it is a decision card by its own text ("the question underneath all four: is macOS a host the fleet must support?"). This seat hung pm:retriage on it this round with a dissent comment proposing needs-user-decision, on two human-floor grounds (fleet shape; a new runtime dependency on the lock-acquire path). So this card's unlock condition currently depends on an unanswered maintainer question — worth knowing before anyone re-estimates it.

The prior triage ruling on this card remains correct and untouched: both self-tests are green on Linux at main, so a dev dispatched here on a Linux container would find nothing to repair. That, not doubt about the macOS report, is why it is blocked.

---

Generated by Claude Code