Repository navigation
[finding] cli checklist: build-own-contract clause 4 vs flag-command-error-ux disagree on exit code 2 — narrow clause 4 to the #4873 duration-leak #7648
Description
Activity
Triage — dual-state resolution:
pm:queue+domain:devxkept;findingremoved (queue+finding is an illegal pair).- Why queue: a scoped checklist reconciliation with a single named edit — narrow
cli.build-own-contractclause 4 to theos migrate成功时退出码是随机非零值(208/171/176/163/62…),--version/--help却干净退出 0 #4873 duration-leak so a legitimate oclifExitError(2) stops reading as a violation. Direction is already settled by the sibling item (flag-command-error-uxasserts 2 is correct), so nothing to rule. - Anchors verified on
origin/main@5823d59: clause text present atdocs/qa/platform-checklist/areas/cli.json:145("exit codes are exactly 0 or 1…");compile.tsthis.error()catches at:411/:480unchanged. Premise holds. - Routing: checklist text ⇒
domain:devx(filing-time label correct; finding: three checklist/doc corrections for thesearcharea (from the #7629 run) #7647/[finding] cli checklist: dev-boot-contract clause 2 names retiredresolveDefaultDevDbUrl/dev.db— refresh to unifiedobjectstack.db#7650 same family, candidates for one sweep PR if the devx lane prefers). - Dedup: no open card on this clause;
os migrate成功时退出码是随机非零值(208/171/176/163/62…),--version/--help却干净退出 0 #4873 is the closed origin of the clause, not a duplicate.
本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
- Why queue: a scoped checklist reconciliation with a single named edit — narrow
Claim: PM loop round 3 (devx seat, 2026-08-11 term) — wave 3 unit E, packed with #7650 (same
cli.json; full claim block on #7650). Branchclaude/issue-7650-7648-cli-checklist; sessionsession_01GZKbx4xyF7U5WXj6ch49BM;mode:cloud,model: opus. This card's half: narrow build-own-contract clause 4 to the #4873 duration-leak it exists to pin, so a legitimate oclifExitError(2) stops reading as a violation — the narrowed clause must stay load-bearing (a duration value in the exit slot must still fail it).
Generated by Claude Code
Pointer — packed with #7650 (same file, one branch, one PR). Full os-dev report lives on #7650: #7650 (comment)
Draft PR: #7712 (first lines
Fixes #7650/Fixes #7648).This card's half —
cli.build-own-contractclause 4, revision 1 to 2:- Before: "exit codes are exactly 0 or 1 (the
CliExitCodeunion) — never a count, never a duration". As phrased it also forbade oclif's standardExitError2, whichcompile.ts's human-paththis.error()catches (:411,:480) legitimately produce on a config-load-time throw — so it contradictedcli.flag-command-error-ux, which asserts that same 2 is correct. - After: narrowed to the
os migrate成功时退出码是随机非零值(208/171/176/163/62…),--version/--help却干净退出 0 #4873 duration-leak it exists to pin — the exit code is a STATUS, never a computed value — with the legitimate exits named explicitly: 0 and 1 viaCliExitCode(everyemitJson/emitTextcaller, i.e. both--jsonpaths here), plus 2 as oclif'sExitErrorwhen the human path ends inthis.error(). A config-load-time throw exiting 2 is the framework's error exit and is no longer a violation;cli.flag-command-error-uxis cross-referenced insourceso the two cannot re-collide. - Still load-bearing: a duration/count reaching the exit slot still FAILS the clause, now by two tests the old wording did not have — a successful run exiting nonzero (the
os migrate成功时退出码是随机非零值(208/171/176/163/62…),--version/--help却干净退出 0 #4873 shape:timer.elapsed()inemitJson's positional exit slot made a successful run exit531 & 0xFF= 19), and any code that moves between two identical runs. A repeat-run step and a matching negative were added so the clause stays falsifiable, and theformat.tssource note was corrected to sayCliExitCodenarrows theemitJson/emitTextslot, not oclif's own error exit.
Premise re-verified at
21888ab:format.ts:41still readsCliExitCode = 0 | 1; boththis.error()catches unchanged, each on the human branch while the--jsonbranch above it answers throughemitJson(...)+this.exit(1). Text-only — nopackages/clichange.
Generated by Claude Code
Generated by Claude Code
- Before: "exit codes are exactly 0 or 1 (the
- added a commit that references this issue
on Aug 17, 2026
Symptom
Two items in the
clichecklist area disagree about exit code 2.cli.build-own-contractclause 4 (docs/qa/platform-checklist/areas/cli.json:145— "exit codes are exactly 0 or 1 (the CliExitCode union) — never a count, never a duration") treats a config-load-time throw that exits 2 as a violation, whilecli.flag-command-error-uxasserts that exit 2 IS the correct oclifExitErrorcode. In the run, a config-load-time throw on the human path exits 2 (reproduced twice) becausepackages/cli/src/commands/compile.ts's catch ends inthis.error()and oclif'sExitErroris 2; theCliExitCode 0|1type only narrows theemitJson/emitTextslot. Every--jsoninvocation exits cleanly (0/1/1/1).Root cause
Checklist reconciliation, not a product defect. Clause 4 was written to pin the #4873 duration-in-exit-slot leak (a timer value reaching the exit-code slot), not to forbid oclif's standard error exit. As phrased it collides with
flag-command-error-ux, which correctly treats exit 2 as the oclif error exit. The clause should be narrowed to the #4873 duration-leak it exists to catch, so a legitimate oclifExitError(2) on a config-load-time throw no longer reads as a violation.Reproduction
Run a
build/compileinvocation whose config fails to load at load time on the human (non---json) path; observe exit 2 fromcompile.ts'sthis.error()catch. Compare againstcli.flag-command-error-ux, which asserts exit 2 as the correct oclifExitError. The two checklist clauses cannot both hold as written. Onorigin/mainthe clause text (cli.json:145) andcompile.ts'sthis.error()catch (lines 411, 480) are unchanged, so the reconciliation is still needed.Source
Extracted from the QA run #7628 (framework 92f26f7, console 6314e87f).