docs: correct the tier_conflict diagnostic description - #150
Open
remyluslosius wants to merge 2 commits into
Open
remyluslosius wants to merge 2 commits into
remyluslosius wants to merge 2 commits into
Conversation
The README and CLI reference described tier_conflict as catching a Tier 1 spec that depends on a Tier 3 spec. No such check exists in the codebase. The implemented diagnostic fires only when a spec's declared tier disagrees with an entry in settings.tier_overrides, and it is a warning, not an error. Both specs confirm the code is correct and the docs were wrong. spec-manifest C-14 describes exactly what CheckTierConflicts does, and spec-check C-01 through C-12 contains no tier-dependency rule. That is why this corrects the documentation rather than the code. The corrected text says the disagreement is reported, not resolved. settings.tier_overrides never changes a spec's effective tier: ResolveTierWithOverrides has no call sites, and the checker reads the declared tier directly. The emitted warning still ends with "using override", which overstates what happens. That is tracked separately. Three pre-existing errors in the same blocks are corrected alongside. The example printed tier_conflict as ERROR when it is a warning. A README orphan-constraint example showed WARN for a spec the adjacent example labels Tier 1, where orphans are errors. The orphan message did not match the format the binary emits. Example output in the CLI reference is now copied from a live run rather than composed by hand. A hand-composed example is how the original claim survived review for so long.
The previous commit edited both files, and the documentation style ratchet requires an edited file to meet the standard. Both failed it, with 66 findings between them, all em dashes. Each em dash became a period, a comma, or a colon, whichever the sentence wanted. Table cells that used an em dash as a "not applicable" placeholder now read n/a. No technical claim changed and the CLI docs parity test still passes. Reading grade is now 9.1 for the README and 7.9 for the CLI reference, against a writing target of 10.0.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
The README and the CLI reference described
tier_conflictas catching "a Tier 1 spec depends on a Tier 3 spec." No such check exists in the codebase, and the README printed it as an ERROR when the diagnostic is a warning.The real diagnostic fires only when a spec's declared
tier:disagrees with an entry insettings.tier_overrides. It reports the disagreement and changes nothing.Why the docs, and not the code
Both specs confirm the code is right:
spec-manifestC-14 describes exactly whatCheckTierConflictsdoes, with AC-19 and AC-20 covering it.spec-checkC-01 through C-12 contains no tier-dependency rule. Its only tier constraint is C-02, orphan severity by tier.Spec and code agree, so the documentation was the defect and no code change was warranted.
Also corrected in the same blocks
Three pre-existing errors, all found while verifying the fix:
tier_conflictexample printed as ERROR. It is a warning.Every example block is now copied from live binary output. A hand-composed example is how the original claim survived review.
A defect this surfaced
The first draft of this fix said the override wins and the declared tier is ignored. That is also false, and it came from trusting the binary's own warning text, which ends
using override (N).Manifest.ResolveTierWithOverrideshas zero call sites.settings.tier_overridesis parsed, compared, and discarded. Measured: a spec declaringtier: 2with an override to1still receives Tier 2 orphan severity and reports as T2 undercoverage.The corrected text says the disagreement is reported, not resolved, and the note under the diagnostics table says the emitted message overstates what happens. Tracked separately, along with the absence of
tier_conflictfromcheck --json.Second commit
Both files failed the documentation style ratchet after being edited, with 66 em-dash findings between them. The second commit clears them. No technical claim changed. Reading grade is now 9.1 for the README and 7.9 for the CLI reference.
Verification
Not included
The same false claim appears in
docs/explainer/blog-2-core-features.md, an unpublished draft that is untracked. The correction is in the working tree and should ride with whatever change publishes those posts.