What
Test Core (1/6) on PR #17990 head fed29ced failed in packages/spec/scripts/gen-sdui-manifest-cleanup.test.ts, case 「reaps the whole session it started, holds no caller fd, and leaves nothing behind」: expect(field('LOCKFDS'), out).toBe('0') received '1' — the caller process still held one lock fd when the test counted. Job: https://github.com/objectstack-ai/objectstack/actions/runs/34750740645/job/103706765153 (started 2026-09-13T10:01Z, attempt 1).
Why it is filed here and not fixed on that PR
- The PR's diff touches
scripts/pm/check-clause2-carriers.mjs and .claude/skills/pm-dispatch/references/contract-review.md only — neither is imported by, nor spawned from, the failing test.
main's Test Core (1/6) is green on the same day (65767d23 10:0x, ae1b2588 11:03, c45ea8c3 11:18).- The skills seat cannot re-run the job (
POST /actions/jobs/103706765153/rerun → 403), so the one confirming re-run has not happened; a second identical failure would make it a real defect of the test's fd accounting rather than a flake. Either way the test lives in packages/spec, so the fix is that lane's.
What a fix would look like (for the owning lane to judge)
The assertion counts fds on the caller after the spawned session exits; if the count can lag the child's exit (fd inherited by a grandchild, or the lock fd closed asynchronously), the test needs to wait on the resource it counts, not on the child's exit status, or take the reading inside the child.
Dedupe keywords
gen-sdui-manifest-cleanup · LOCKFDS · Test Core (1/6) · flaky shard · os-heavy-verify.lock
Source
Filed by the skills execution seat (session session_01DAcomhvR9kKizeYgg89Vo8) from the red on PR #17990; the PR's contract review (5652701385) and 速读 (5652701490) record the reading. Left bare for triage per ruling ③ (#17942, 5652544529): grading and routing are triage's; this filer did not pull the board (one targeted search on 2026-09-13 found no open card naming this test).
Generated by Claude Code
What
Test Core (1/6)on PR #17990 headfed29cedfailed inpackages/spec/scripts/gen-sdui-manifest-cleanup.test.ts, case 「reaps the whole session it started, holds no caller fd, and leaves nothing behind」:expect(field('LOCKFDS'), out).toBe('0')received'1'— the caller process still held one lock fd when the test counted. Job: https://github.com/objectstack-ai/objectstack/actions/runs/34750740645/job/103706765153 (started 2026-09-13T10:01Z, attempt 1).Why it is filed here and not fixed on that PR
scripts/pm/check-clause2-carriers.mjsand.claude/skills/pm-dispatch/references/contract-review.mdonly — neither is imported by, nor spawned from, the failing test.main'sTest Core (1/6)is green on the same day (65767d2310:0x,ae1b258811:03,c45ea8c311:18).POST /actions/jobs/103706765153/rerun→ 403), so the one confirming re-run has not happened; a second identical failure would make it a real defect of the test's fd accounting rather than a flake. Either way the test lives inpackages/spec, so the fix is that lane's.What a fix would look like (for the owning lane to judge)
The assertion counts fds on the caller after the spawned session exits; if the count can lag the child's exit (fd inherited by a grandchild, or the lock fd closed asynchronously), the test needs to wait on the resource it counts, not on the child's exit status, or take the reading inside the child.
Dedupe keywords
gen-sdui-manifest-cleanup · LOCKFDS · Test Core (1/6) · flaky shard · os-heavy-verify.lock
Source
Filed by the skills execution seat (session
session_01DAcomhvR9kKizeYgg89Vo8) from the red on PR #17990; the PR's contract review (5652701385) and 速读 (5652701490) record the reading. Left bare for triage per ruling ③ (#17942, 5652544529): grading and routing are triage's; this filer did not pull the board (one targeted search on 2026-09-13 found no open card naming this test).Generated by Claude Code