Skip to content

feat(check): add --strict so a failed check exits non-zero - #193

Merged
Bccorb merged 1 commit into
mainfrom
feat/check-strict-exit
Sep 5, 2026
Merged

feat(check): add --strict so a failed check exits non-zero#193
Bccorb merged 1 commit into
mainfrom
feat/check-strict-exit

Conversation

@Bccorb

@Bccorb Bccorb commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Refs #166

#166 asks to "decide the seamless check exit-code question, here or in a linked issue". #192 took the other branch it offers (the smoke job asserts independently), so that job does not depend on this. This is the decision, sent separately because it is a user-facing CLI flag rather than a CI change, and it touches all thirteen check sites.

The problem

From the issue, and reproduced:

$ seamless check          # in an empty directory
seamless.config.json not found
Run: seamless init
exit=0

$ seamless check          # scaffolded project, stack down
API not reachable
Auth not reachable
Console not reachable
Check complete.
exit=0

An empty directory, a stack that is down, and a fully healthy project are indistinguishable to anything reading the exit status. check is exactly the command you would put in a health-check script, and it cannot be used in one.

The fix

--strict exits 1 when any check failed, naming the count:

$ seamless check --strict
...
3 checks failed.
exit=1

Two decisions worth stating:

The default is unchanged. Anything parsing this output today keeps working, and a sudden non-zero exit would break it silently. That is why this is a flag rather than new default behaviour, as the issue suggests.

Every check still runs. Results go through a small Report that counts failures instead of throwing, so --strict decides the exit status only after the full report has printed. A gate that stops at the first problem hides the rest, and the whole picture is the reason to run check at all. There is a test for this: a project failing eight ways prints all eight and reports 8 checks failed.

The refactor

All thirteen pass/fail sites moved from bare console.log to report.ok(...) / report.fail(message, remedy?). That is what makes the count possible, and it also collapses the repeated two-line "failure then remedy" pattern into one call.

runCheck takes args so index.ts can pass the flag through; it defaults to [], so existing callers and tests are unaffected.

Verification

npm run build and npm test pass, 916 tests. 5 new tests. Also checked against the real binary rather than only through mocks:

no flag, empty dir:  exit=0
--strict, empty dir: exit=1

helpTopics.ts documents the flag, per the convention in AGENTS.md that the help registry is the single source. README does not mention check at all, so there is nothing to update there.

check is what anyone reaches for in a health-check script or a CI gate, and it
always exited 0. An empty directory, a stack that is down, and a healthy project
were indistinguishable to anything reading the exit status.

--strict exits 1 when any check failed and reports the count. The default is
unchanged, since this output has been parsed by scripts since before the flag
existed.

Results now go through a small Report rather than straight to console.log, so
every check still runs before the exit decision: a gate that stops at the first
problem hides the rest, and the whole picture is the reason to run check.

Refs #166
@Bccorb
Bccorb merged commit 3fcaa9a into main Sep 5, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant