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
§DF-a-near-miss-title-citation-is-a-citation, §FS-citations.recognized.title-lines, §REQ-backwards-compatibility.5, §REQ-no-missed-citation.2: a citation in a near-miss declaration's title is now a citation. A heading check reports as declaration-near-miss, such as # FS-beta: Beta, per a cited FS-001-alpha under the default {kind}-{number}-{slug}, now cites it, as a conforming declaration's title has since 0.18.0: refs FS-001-alpha lists it, and FS-001-alpha is no longer reported unused. This holds in every form a near miss takes, Markdown headings and doc comments alike, and only a citation of the near miss's own ID, as written, is still dropped. Who this breaks: a repository whose near-miss headings cite other IDs in their titles. The verdict moves both ways: a title citation there that dangles, names a missing section or an unknown project alias, or is a number-only shorthand is now an error (dangling, missing-section, unknown-project, shorthand-citation), a direction rule now judges it (forbidden-citation, discouraged-citation), a glob there is a glob-citation error, and every finding names its location and the fix, as for a citation anywhere else. Renaming the ID to the configured format, as the declaration-near-miss error asks, no longer changes what its title cites.
§DF-agent-setup-instructions-removed-in-0-20, §FS-init.5.7, §REQ-backwards-compatibility.2: grund agent-setup-instructions is removed; run grund guide setup, which prints the same text. What grund 0.19.0 announced lands: the name is no longer a command, so grund agent-setup-instructions is read as an ID query and fails with invalid ID `agent-setup-instructions` , prints nothing on stdout and exits 1, and grund help agent-setup-instructions is error: unknown command: agent-setup-instructions with exit 2. Who this affects: a script, CI step or agent instruction that still runs grund agent-setup-instructions, which saw the deprecation warning in 0.19.0: change it to grund guide setup, or to grund guide --full for the whole guide. The Python and Node agent_setup_instructions() and agentSetupInstructions() keep their names and are unaffected. Closes issue #930.
§FS-init.2.3.4.3: The managed block teaches grund list --unused. The cheap-grounding list in the grund init block gains one bullet, - `grund list --unused` — the declarations nothing cites yet, in one call, directly after the grund list --kind one, so an agent that reads only the block lists the uncited declarations in one call instead of running grund refs per ID. What an upgrader does: run grund init once, which the block versions v39/v40 and v41/v42 of this release already ask for. (#937)
grund check now compares the whole managed grund init block in AGENTS.md and its companions with what grund init would write, not only its five generated sections: a block that no longer matches its config — after editing kinds, titles, the ID format, the marker, named sections or the inline-style keys, or after grund config migrate --write — is an agents-init error naming each differing section; run grund init to refresh it.
At the outermost root of a workspace, in a checkout with every member, check also compares each block's Project namespaces and Workspace members sections, so a member joining or leaving, or a member's description, reports the blocks it makes stale, each naming the directory to run grund init in (run `grund init` in packages/billing to refresh); a run inside a member, or in a checkout without an optional member, leaves those two sections out, and the optional-member-absent warning says so when the run verified a managed block. agents-init findings about another project's block that name a command, and the optional-member-absent warning, grow at the end (; run it in <dir>, , nor the managed blocks' workspace sections); the code and the JSON shape are unchanged.
The block versions stay v39/v40 and v41/v42, shared with the Citation directions change of this release, so every earlier block is already reported outdated and one grund init per project, in any order, clears both; from now on, any change grund makes to the block's text moves its version. grund config migrate refuses what it refused before; its Project map note now ends grund check reports the block stale until then.
Rust, Python and Node check report arrays now follow §FS-errors.4.1 consistently across single-project and workspace runs; update order-sensitive expectations. Findings, CLI output and verdicts are unchanged. Closes issue #952.
A successful grund config migrate --to 2 --write no longer prints the candidate or mapping report; --full brings both back.
A refused one ends with its causes and remedies, without completed-write defaults or next-init advice; its refusal verdict is unchanged.
A non-citable home whose row grounds nothing now renders its Citation directions bullet as Each file in **tests/e2e/** that cites anything must cite FS., followed by a sentence saying a file there that cites nothing is not checked and naming the setting that makes it a finding. A home whose own row turns grounding on is now named in the grounding sentence. The managed block's versions advance from v35/v36 to v39/v40 and from v37/v38 to v41/v42. Existing blocks are reported outdated by grund check and grund init --check; run grund init to refresh them, preserving unmanaged text. No verdict over the repository's own files changes.
§DF-e2e-manifest-args, §FS-show.2.4.2, §FS-distribution.3.2.2.3: an E2E case with no command.args now reports "args":[].grund show E2E-<name> --format json, the Python and Node show manifest.args, and the scan snapshot's e2eCase.args gave ["check"] for a case whose directory has no command.args, against the specification, which says []. They now give []; a case that has command.args reports its words as before. The text form is unchanged, and still opens with grund check for such a case. Who this affects: a consumer that read ["check"] as the default invocation: read an empty args as "no manifest, runs grund check". Closes issue #947.
§DF-image-index-entry-lands-in-0-20, §FS-citations.checks.image-index-entry, §FS-check.3.18, §REQ-backwards-compatibility.2: A citation-only image in a kind's index is no longer an entry. What grund 0.19.0 announced with the image-index-entry warning lands: an index row such as  neither lists <ID> nor enrolls an external source declaration. An ID whose only entry was such an image is reported as missing-index-entry, an error at the declaration's heading that says the ID appears in the index but not as an entry, so grund check exits 1, and an external declaration that only such an image enrolled is no longer a member of the index. The image-index-entry code is spent: it never fires, and --only and --ignore still accept it. Who this affects: an index that drew the image-index-entry warning in 0.19.0: write the link that warning named, [§<ID>](decisions/functional/<link>), beside the image, which may stay. Closes issue #930.
§FS-init.2.2.2.3: grund init's next: block names a kind and a home your project declares. In a project with kinds but no FS kind, or with an FS row that has no home, grund init no longer tells you to scaffold docs/functional-spec and to run grund id FS. It teaches grund id <KIND> for FS where FS has a home, otherwise for the first citable kind with a home, otherwise for the first citable kind, in configuration order, under that kind's first file or folder. It asks you to create that home only while it is missing, and to declare the ID in a source doc-comment where the kind has none. A refresh whose selected home exists, such as the one grund check asks for after grund config migrate --to 2 --write, now prints no next: block. What moves: stderr of grund init, --dry-run and --check in such projects; no exit code and no written byte. The Rust InitNext gains allocation: Option<InitAllocation>, carried as allocation by the Python and Node packages; a Rust caller building InitNext with a struct literal adds the field. (#940)
§FS-init.2.3.4.15.8: grund init keeps a block's member list while an optional member is absent. In a checkout without a [workspace] optional_members entry, grund init and grund init --check, at the root and in each present member, keep the ### Workspace members section of an existing managed block exactly as it is and refresh the rest of the block, as grund check already leaves that section out there; --force keeps it too. A block written new there lists only the members the run can read. Each run prints one note: per absent member saying whether each entrypoint's section was kept or written new. What moves:grund init --check in such a checkout exits 0 where it exited 1 when the member list is the only difference, and grund init there no longer drops the member from the list. Refresh the member list from a checkout that has every member. (#921)
§FS-init.2.3.4.15.6: A workspace member link names the member's directory. Each bullet under ### Workspace members now links the foreign project's root directory, as - [`billing`](decisions/functional/packages/billing/) or - [`shop`](./), whether or not that project has been initialized; the link to its AGENTS.md and the *(not yet initialized)* suffix are gone. One grund init in each project of a fresh workspace, in any order, now leaves grund check at the workspace root green, where the project initialized first used to be reported stale. What an upgrader does: run grund init once in each workspace project, which the block versions v39/v40 and v41/v42 of this release already ask for. (#931)
§DF-refs-unused-note, §FS-refs.2.1.1: grund refs points at grund list --unused when a declared ID has no citations. A query such as grund refs FS-login for a declaration nothing cites still prints nothing on stdout, or not cited under --total, and still exits 0, and now also writes note: FS-login is declared but nothing cites it; `grund list --unused` lists every such declaration to stderr. An alias-qualified query names --project <alias>, an E2E case adds --kind E2E, and the note is withheld for an explicit path, a section, --glob, --from and an incomplete scan. Who this affects: a script that treats any stderr output from a successful refs run as a failure, and a Rust, Python or Node caller that reads a non-null note on a refs result as a typo. Stdout and exit codes are unchanged.
§FS-errors.3.6.1: the stale managed-block finding names its section as one subject.grund check's agents-init error for a block section that no longer matches read <section> differ from grund.toml, which is wrong for a singular section such as scoped guidance. It now reads the <section> section differs from grund.toml, for example repo maintenance: stale grund init block: the scoped guidance section differs from grund.toml — run `grund init` to refresh (does not affect citation validity). Who this affects: a script matching the words after repo maintenance: stale grund init block: in the text line, the message in --format=json, or the message of a Python or Node finding. Match code == "agents-init" instead. The code, the severity, the line, the exit status, the JSON shape and that leading prefix are unchanged. Closes issue #933.
