You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
§FS-check.3.30, §FS-workspace.2.1, §FS-config.4.3, §REQ-backwards-compatibility.2: a [workspace] block whose members swallow its own scan now fails to load. The ramp every 0.13.x to 0.15.x binary announced in its own output lands on the release it named: warning: grund.toml:16: [workspace] members swallows this project's whole scan — every scan root is inside a member: `docs` in `docs` — so its declarations are unreachable and its citations are never checked. Point [scan] include at a directory that is not a member, or set include_root = false. This becomes an error in grund 0.16.0. at the command's own exit becomes error: grund.toml:16: [workspace] members swallows this project's whole scan — … Point [scan] include at a directory that is not a member, or set include_root = false; this became an error in grund 0.16.0 at exit 2, with nothing on stdout, under --format json too. It is located at the block's members line like every other members error, and it wins over a later expansion refusal in the same tree. init is the exception: it is how a broken workspace gets repaired, so it neither refuses nor prints the warning any more. §RM-workspace-absorbed-scan-error loses its plan but keeps its address and heading text as a pointer, because released changelogs cite it, and §FS-check.4.7 and §FS-check.4.7.9 stay behind as pointers for the same reason. Nine e2e cases move to exit 2: workspace-member-absorbs-scan-list, -check, -check-json, -full, -glob-symlink, -nested, -default-include, -expansion-error and -expansion-error-json. What does not move: the rule of §FS-workspace.2.1 and its exclusions, the covered pairs the message names, and both fixes — include_root = false or a [scan] include that is not a member; workspace-member-absorbs-scan-partial and workspace-member-absorbs-scan-include-root-false stay green untouched. Who this breaks: a repository whose [workspace] members cover every one of the block's scan roots — every walking command exits 2 where it exited 0 or 1. Closes issue #443. (PR #446)
§FS-cli.1, §FS-cli.4, §REQ-backwards-compatibility.2: bare grund no longer runs grund check .. The deprecation window the warning named closes on the release it named, so the path's worked example is now a path performed end to end: grund with no arguments is a CLI-level error — empty stdout, exit 2, and on stderr error: no command given; the bare `grund` fallback that ran `grund check .` was removed in grund 0.16.0 followed by two hint: lines naming grund check and grund --help. Who this breaks: a CI step still spelled grund, which was green having validated the repository and is now red having validated nothing; the line to write instead is grund check, which is what the error says. grund check, grund <ID>, grund --help, grund --version and grund . are untouched, and §FS-cli.5's report-to-exit mapping does not move — bare grund moves between two codes that mapping already defines. Why the landing is an error rather than the top-level help page, which would be stdout and exit 0 and so the successful no-op the window was bought to prevent, is §DF-bare-grund-lands-on-an-error. What docs/changelog/0.3.0.md announced eleven releases ago is now true of the removal and false of the landing — bare grund no longer runs grund check ., and it does not print the top-level help either; that archived section is left as it stands. Closes issue #301. (PR #331)
§FS-rules.checks.unreached-declaration, §FS-rules.7, §FS-rules.7.7, §FS-rules.3.1, §FS-rules.10, §FS-errors.5.5, §REQ-backwards-compatibility.2, §DF-chapter-rule-reaches-every-declaration.2.5: an unreached declaration now fails grund check. The ramp every 0.15.x binary announced in its own output lands on the release it named: unreached-declaration is an error on the ordinary must channel, so docs/fs/FS-login.md:1: warning: FS-login has no requirements chapter, so RULE-requirements cannot reach it; add the chapter, or narrow the rule to the declarations that have one; this warning becomes an error in grund 0.16.0 at exit 0 becomes the same line at error: ending ; this became an error in grund 0.16.0 at exit 1. The rules report stops having a warnings channel at all, the engine's two-field required-level return collapses back to one Vec as §DF-chapter-rule-reaches-every-declaration.2.5 said it would, and §FS-rules.7.7 is kept as a pointer — heading text included — so the citations written during the ramp still resolve. §RM-unreached-declaration-error loses its plan, as a shipped milestone's is removed, but keeps its address and its heading text as a pointer while #362's bullet in the 0.15.0 release and this notice still cite it (§FS-distribution.4.6.4). Retiring that address is a change of its own: this notice is a section of a decision record, so the repoint the roadmap's lead prescribes need not wait for a release. Exactly two e2e cases move with it — check-rules-chapter-absent-declaration and check-rules-chapter-absent-families, both from exit 0 to exit 1; check-rules-chapter-absent-paired was already 1 and check-rules-chapter-absent-suggestion stays 0. What does not move: the code, the location at the subject declaration's title line, the one-finding-per-semantic-group identity, the three positive citation families it fires for, prohibition's silence, the recommended level's ramp-free suggestion, and --only / --ignore unreached-declaration — which now clears the exit code along with the finding, as it does for every other error. A paired chapter-presence rule still prints its own chapter-cardinality line and still suppresses nothing. Who this breaks: a repository with a chapter-scoped must citation rule over a kind one of whose declarations lacks the chapter — its run exits 1 where it exited 0, having written nothing in between, and it has three one-line escapes: add the chapter, narrow the rule's subject to the declarations that have one, or pass --ignore unreached-declaration. A --format json or LSP consumer reads "severity":"error" under an unchanged code, and a consumer matching the message's last clause exactly sees it change. A repository with no rules = true kind is byte-for-byte unchanged. §FS-errors.3 is satisfied rather than waived: the stable-phrasing rule admits a deprecation path, §REQ-backwards-compatibility.2 is the path this took — the warning shipped in 0.15.0 naming 0.16.0 in its own bytes — and §FS-distribution.4.2 positively requires the landed wording once the ramp lands, so the pending clause could not have stayed. What survives is a verbatim contiguous prefix in §FS-errors.3's own terms, ending at have one, so every prefix matcher and every code consumer reads what it read before. Because the tree now reports 0.16.0 in the past tense, no version below it can be cut from here on (§FS-distribution.4.2.6). Closes issue #368. (PR #369)
§FS-fmt.2.3.5, §REQ-no-missed-citation.2, §REQ-backwards-compatibility.5, §DF-inline-code-span-closes-on-its-own-run: a Markdown inline code span now closes at the next run of backticks as long as the one that opened it, as CommonMark reads it, so a citation after a double-backtick span that holds a single backtick is prose again. grund fmt paired backticks one at a time, so it read the rest of such a line as code: fmt --write left a stale cross-reference anchor there and reported the file clean, and the broken link reached a commit; inside such a span it read the text before the inner backtick as prose and rewrote a citation in code. One predicate answers for every pass of fmt, the LSP on-type transform and every inline-code reading of grund check, so they move together. An opener that does not close on its line still leaves the rest of the line code, because a span may continue onto the next line. The verdict moves both ways, and four ways a passing tree can now fail are named in the decision: fmt --check asks for the rewrite a citation after the span was always owed; check raises the canonical-form error for a number-only shorthand after the span; a wrapped index entry inside a span stops being an entry; and in a workspace source file a marked qualified citation inside a span is skipped, so its declaration may go uncited. Every finding that replaces the old verdict names its location and the action to take: run grund fmt --write, or move the entry or the citation out of the span. Closes issue #440. (PR #441)
§FS-check.1.4, §FS-check.2.1.2, §FS-rules.7.6, §DF-narrowed-check-keeps-invalid-rule, §REQ-backwards-compatibility.5, §REQ-no-missed-citation.1: a check narrowed to a code rules produce keeps the invalid-rule errors. Selecting any of the eight rule-produced codes — chapter-cardinality, citation-cardinality, uncited-unit, unreached-declaration, missing-citation, forbidden-citation, discouraged-citation, suggested-citation — with --only now also selects invalid-rule, every row of it, so a rule that could not run is never read as a pass. Who this breaks: the verdict moves from exit 0 to exit 1 for a run narrowed to a rule-produced code over a tree holding an invalid rule: grund check --only chapter-cardinality over a rule written as its heading line alone printed success and now prints docs/rules/RULE-chapters.md:1: error: RULE-chapters is not a valid rule: rule rationale is empty, and its --format json form prints that row where it printed nothing. Every finding that replaces the old verdict is the row the unnarrowed grund check already prints, naming the rule's location and why it was refused, which is where the fix goes, so no tree that passes the unnarrowed check fails after. The opt-out:--ignore invalid-rule still wins and restores the old view, and --only-rule still drops a declared rule's row beside a --rule trial sentence. A selection that names no rule-produced code is unchanged. Closes issue #421. (PR #438)
§FS-declarations.checks.declaration-near-miss, §FS-declarations.checks.declaration-near-miss.5, §FS-errors.5.5, §REQ-backwards-compatibility.2: a declaration off its [id] format now fails grund check. The ramp every 0.14.x and 0.15.x binary announced in its own output lands on the release it named: docs/FS-billing.md:1: warning: `FS-billing` resolves for compatibility but does not match [id] format = "{kind}-{number}-{slug}" — rename it or change the effective format; this warning becomes an error in grund 0.16.0 at exit 0 becomes the same line at error: ending ; this became an error in grund 0.16.0 at exit 1, and JSON and the LSP report "severity":"error". §RM-off-grammar-declaration-error loses its plan but keeps its address and heading text as a pointer, because released changelogs cite it. Two e2e cases move from exit 0 to exit 1: check-declaration-near-miss and config-id-format-per-kind-override. What does not move: the code, the location at the declaration line, the facts the message states, and the catalog-backed compatibility of §FS-config.3.2 — show, refs, list, cover, fmt and LSP navigation still resolve the ID and its exact marked citations exactly as they did. Who this breaks: a repository holding a declaration whose ID does not match its effective [id] format, including one that resolves only for compatibility — its check exits 1 where it exited 0. The fixes are the ones the message names: rename the declaration and its citations, or change the effective format; --ignore declaration-near-miss removes the finding and the exit together. A consumer matching the message's last clause exactly sees it change; a code consumer reads the same code. Closes issue #443. (PR #446)
§FS-refs.4, §FS-output-shapes.6.1.2, §FS-errors.2.3, §REQ-backwards-compatibility.2: grund refs on an invalid ID or an ambiguous number-only shorthand now exits 1, a failed query. The window every 0.14.x and 0.15.x binary announced in its own output closes on the release it named: error: invalid ID `FS-bar` , the configured-format hint:, and warning: `grund refs` invalid IDs and ambiguous number-only shorthands currently exit 2; they will exit 1 (failed query) in grund 0.16.0 at exit 2 become exactly what grund show prints — invalid ID `FS-bar` and the hint, or ambiguous ID: FS-042 (matches FS-042-user-login, FS-042-user-logout) — at exit 1. Under --format json the raw text becomes the shared failed-query object, {"severity":"error","path":null,"line":null,"code":"invalid-id","message":"invalid ID `FS-bar`","sites":null,"authority":null} (code ambiguous for the shorthand), with no hint. --summary, --section, --descendants and --total follow the same path. Five e2e cases move from exit 2 to exit 1: refs-invalid-id-format, refs-invalid-id-format-json, refs-total-invalid-id, refs-ambiguous-shorthand and refs-ambiguous-shorthand-json. What does not move:grund show's bytes, an unknown alias and a scan or I/O failure at exit 2, and a resolved ID with no citations at exit 0. Who this breaks: a script that read exit 2 from grund refs as "fix the ID", or matched the error: prefix or the warning line — it now reads exit 1 and the bare message. Closes issue #443. (PR #446)
§FS-declarations.checks.unmarked-heading, §FS-declarations.checks.unmarked-heading.5, §FS-errors.5.5, §REQ-backwards-compatibility.2: an unmarked heading inside a declaration body now fails grund check. The ramp every 0.14.x and 0.15.x binary announced in its own output lands on the release it named: docs/FS-heading-policy.md:5: warning: unmarked heading inside FS-heading-policy; number it (### 1. Origin of the fails queues) as FS-heading-policy.1, declare an ID, or use a bold label; this warning becomes an error in grund 0.16.0 at exit 0 becomes the same line at error: ending ; this became an error in grund 0.16.0 at exit 1, and JSON and the LSP report "severity":"error". §RM-unmarked-heading-error loses its plan but keeps its address and heading text as a pointer, because released changelogs cite it. Seven e2e cases move from exit 0 to exit 1 — check-unmarked-heading, -json, -boundaries, -suggestions, -only, -level-loose and -level-warn — and three that already exited 1 regroup their lines. What does not move: the code, the location at the heading line, the nearest enclosing declaration, the deterministic suggested coordinate, the exempt headings, --full's narrowing to the configured scan scope, [id] section_heading_levels (which governs only section-heading-level and never softened this rule), and every command other than check — no command numbers the heading. Who this breaks: a repository with an unnumbered ATX heading inside a Markdown declaration body — its check exits 1 where it exited 0. The fixes are the ones the message names: number the heading as suggested, declare an ID, or use a bold label; --ignore unmarked-heading removes the finding and the exit together. A consumer matching the message's last clause exactly sees it change; a code consumer reads the same code. Closes issue #443. (PR #446)
