Problem
Today, if a user hits a weird FerrFlow behaviour — bad version bump, unexpected tag, no commits detected — their only recourse is --verbose + staring at logs. There's no first-class way to say "is my setup sane?".
Proposal
New subcommand ferrflow doctor that runs a series of read-only checks against the current repo + config and prints a categorised report. Think kubectl cluster-info dump / homebrew doctor.
Checks to run:
Repo
- Is this a git repo? (
git2::Repository::discover succeeds.)
- Is the working tree clean? (uncommitted changes are fine but flagged as warning — release operations would refuse anyway.)
- Is there at least one commit on the current branch?
- Is there a remote? Can it be resolved?
- Are tags fetched from the remote? (
git fetch --tags + compare counts.)
Config
- Does
.ferrflow.json / .toml / .ferrflow exist? If multiple, which one wins?
- Does it parse against the JSON schema?
- Do all
path: values in package[] resolve to directories?
- Do
versioned_files[].path resolve to files?
- Are there packages with
depends_on entries that don't match any declared package?
Versioning strategy
Forge
- Can we detect the forge (GitHub / GitLab / Gitea / Bitbucket) from the remote URL?
- Is the auth token present in the environment? Is it readable (no need to call the API — just check that
GITHUB_TOKEN etc. is set to a non-empty value).
- Optional
--online flag: actually call the forge's whoami / rate-limit endpoint and report the available calls + expiry.
CI
- Is a
.github/workflows/ or .gitlab-ci.yml or .forgejo/ directory present?
- Does any workflow reference
FerrFlow-Org/ferrflow@? What version?
Output
- Default: human-readable with ✓ / ⚠ / ✗ glyphs per check, grouped by section.
--format=json for CI scripting.
- Exit code 0 if all green, 1 if any warnings, 2 if any errors.
Acceptance
- Fresh
ferrflow doctor on a pristine repo explains what's missing to start a release.
- On a misconfigured repo, the report pinpoints the exact line / file / value.
--format=json output is stable enough to assert on in fixture tests.
Related: #333 (ferrflow init wizard) — once init lands, doctor is what you run afterwards to confirm.
Problem
Today, if a user hits a weird FerrFlow behaviour — bad version bump, unexpected tag, no commits detected — their only recourse is
--verbose+ staring at logs. There's no first-class way to say "is my setup sane?".Proposal
New subcommand
ferrflow doctorthat runs a series of read-only checks against the current repo + config and prints a categorised report. Thinkkubectl cluster-info dump/homebrew doctor.Checks to run:
Repo
git2::Repository::discoversucceeds.)git fetch --tags+ compare counts.)Config
.ferrflow.json/.toml/.ferrflowexist? If multiple, which one wins?path:values inpackage[]resolve to directories?versioned_files[].pathresolve to files?depends_onentries that don't match any declared package?Versioning strategy
next-version).Forge
GITHUB_TOKENetc. is set to a non-empty value).--onlineflag: actually call the forge'swhoami/ rate-limit endpoint and report the available calls + expiry.CI
.github/workflows/or.gitlab-ci.ymlor.forgejo/directory present?FerrFlow-Org/ferrflow@? What version?Output
--format=jsonfor CI scripting.Acceptance
ferrflow doctoron a pristine repo explains what's missing to start a release.--format=jsonoutput is stable enough to assert on in fixture tests.Related: #333 (
ferrflow initwizard) — once init lands,doctoris what you run afterwards to confirm.