Problem
docs/doctor-findings.md:75's example JSON for basectl check --format json output shows the key "profiles": []. The real field name is profile_checks, and it's only present at all when --profile <list> is passed.
Confirmed live: basectl check --format json (no profile) returns keys ['schema_version', 'status', 'checks'] -- no profiles/profile_checks key at all. basectl check --profile dev --format json returns ['schema_version', 'status', 'checks', 'profile_checks'].
The example directly contradicts the very next paragraph in the same file, which correctly names the field profile_checks.
Why this matters
This is a copy-paste-ready example in a reference doc, sitting one paragraph above text that correctly names the field differently -- a reader who copies the example JSON shape into a parser would build against a field name (profiles) that doesn't exist and miss the one that does (profile_checks), and would also not learn that the field is conditional on --profile being passed.
Proposed change
Fix the example to use profile_checks instead of profiles, and make clear (as the following prose already does) that the field is only present when --profile is passed -- either by showing the no-profile example without the key, or by adding a second example with --profile that includes it.
Acceptance criteria
Problem
docs/doctor-findings.md:75's example JSON for
basectl check --format jsonoutput shows the key"profiles": []. The real field name isprofile_checks, and it's only present at all when--profile <list>is passed.Confirmed live:
basectl check --format json(no profile) returns keys['schema_version', 'status', 'checks']-- noprofiles/profile_checkskey at all.basectl check --profile dev --format jsonreturns['schema_version', 'status', 'checks', 'profile_checks'].The example directly contradicts the very next paragraph in the same file, which correctly names the field
profile_checks.Why this matters
This is a copy-paste-ready example in a reference doc, sitting one paragraph above text that correctly names the field differently -- a reader who copies the example JSON shape into a parser would build against a field name (
profiles) that doesn't exist and miss the one that does (profile_checks), and would also not learn that the field is conditional on--profilebeing passed.Proposed change
Fix the example to use
profile_checksinstead ofprofiles, and make clear (as the following prose already does) that the field is only present when--profileis passed -- either by showing the no-profile example without the key, or by adding a second example with--profilethat includes it.Acceptance criteria
basectl check --format jsonoutput field names.