init exits 1 on a healthy local repository, because a skipped check counts as needing attention

[MongLong0214]

Reproduced myself in a fresh git init repository with no remote — the state every project starts in.

$ commitlore init
[1/4] hooks install            ok
[2/4] index --rebuild          ok
[3/4] claude hook install      ok
[4/4] doctor --fix
        ok      cli runtime
        ok      notes push
        ok      commit-msg hook
        ok      hook runtime
        ok      PreToolUse hook runtime
        ok      git interpret-trailers
        ok      history depth
        ok      index health
        skipped squash conservation — nothing to check

init: 4/4 steps ran, 1 need(s) attention — doctor --fix
                                                            exit 1

Every check is ok. The only non-ok line is a skipped, which by its own wording means there was nothing to check. init counts it as needing attention and exits 1.

Why this matters more than an off-by-one

init is the onboarding command — the first thing a new user runs, and the command the README's first screen leads to. It reports failure on a perfectly healthy setup, in the most common starting state there is.

It also trains the wrong reflex. A user who sees exit 1 on their first successful run learns that init's exit code means nothing, and stops reading it — which is precisely when it will matter.

Under #65's convention, exit 1 means "ran, found what the caller asked about". A skipped check found nothing. This should be 0.

Also reported independently

An agent working in another project hit the same thing and reported it as friction: " exited code 1 despite 4/4 steps completing, solely because found a non-fatal warn-level issue unrelated to this repo's work — a warning escalated to a failing exit code." Two independent sightings within the hour.

What a fix must get right

• skipped is not warn. Do not collapse the two.
• A genuine warn that init cannot resolve itself should still exit non-zero — that behaviour is correct and was deliberate. Only skipped is miscounted.
• Verify against both: a fresh no-remote repo must exit 0, and a repo with a real unresolvable warning must still exit 1. A fix that makes init always exit 0 is worse than the bug.

[MongLong0214]

Correcting my own issue body — I got the cause wrong, and the shell mangled two lines when I filed it.

The real cause is not a skipped check. There is a genuine warning:

warn    notes fetch refspec — no remote is configured, so records cannot be shared with anyone

Every other check is ok; squash conservation is skipped. So init counts one real warn and exits 1, which under #65 is defensible on its face.

The defect is narrower and still real: "no remote configured" is the normal state of a repository that was just created, not a problem to fix. git init followed by commitlore init is the documented first-run path, and it reports failure at the end of a setup that succeeded completely.

The warning itself is correct and worth printing — records genuinely cannot be shared without a remote, and a user should know. What is wrong is treating it as needing attention when the user did nothing wrong and init could have done nothing differently.

Revised fix

Distinguish a warning about a state not reached yet from a warning about something misconfigured. No remote is the first kind. A remote whose notes refspec is broken is the second, and that one must still exit non-zero.

Verify against three cases, not two:

• fresh git init, no remote → exit 0, warning still printed
• remote configured correctly → exit 0
• remote present but notes refspec broken → exit 1

The third case is #63's incident and the exit code must not regress on it.

Worth checking the same distinction in doctor itself, where the warn originates. If doctor cannot tell the two apart, init cannot either.