knodin 0.5.0

package/docs/INDEXING-POLICY-AND-PROVENANCE.md

@@ -0,0 +1,37 @@
+# Indexing policy and provenance
+
+knodin distinguishes source, generated, vendored, mirrored, ignored, and
+duplicate-candidate content.
+
+Policy precedence is:
+
+1. explicit `reckon.yaml` analysis policy;
+2. established `.gitattributes` generated/vendored signals;
+3. source maps, generated headers, build metadata, SBOM, or SLSA evidence;
+4. bounded inference, always labeled with confidence.
+
+Git ignore and knodin analysis policy are different. knodin must never add a
+tracked file to `.gitignore` or `.git/info/exclude` merely because
+`index.exclude` omits it from analysis.
+
+Provenance relationships are `generated_from`, `vendored_from`, `mirror_of`,
+and `duplicate_candidate`. Exact content equality creates only a
+`duplicate_candidate`; a hash cannot prove lineage. Hashing must stream large
+files rather than loading whole trees into memory.
+
+Declared generated, vendored, or mirrored repositories default to
+provenance-only indexing. Full indexing requires an explicit override. Queries
+against a derived artifact identify or redirect to canonical source when
+source-evidenced provenance is available.
+
+System configuration imports bounded `.gitattributes`
+`linguist-generated`/`linguist-vendored` entries, generated-file headers,
+source-map sources, CycloneDX PURLs, and SLSA/in-toto material URIs as
+source-located policy or relationship evidence. These lower-authority signals
+never override an explicit repository role or `index: full` choice. A generated
+header without a named source is policy evidence only; knodin does not invent a
+`generated_from` target.
+
+Every stored relationship retains evidence location, adapter/extractor,
+evidence kind, confidence, target identity, freshness, and index generation.
+Unknown or stale evidence remains explicit.

package/docs/INSTALLATION.md

@@ -0,0 +1,208 @@
+# Installing knodin
+
+**knodin — source-evidenced local code intelligence with known bounds.** It is a
+local code-intelligence engine, CLI, and single-tool MCP
+gateway. npm is the primary cross-platform distribution. Every persistent
+installation must resolve one stable `knodin` executable from interactive
+shells, Git hooks, and MCP clients.
+
+## Support and evidence
+
+| Installer or manager | Command | Current status |
+| --- | --- | --- |
+| npm without a Node manager | `npm install --global --ignore-scripts knodin@<version>` | Verified by the packed-consumer gate on macOS/Linux |
+| mise npm backend | `mise use --global npm:knodin@<version>` | Executable gate provided; release verification requires the published version |
+| Volta | `volta install knodin@<version>` | Guidance from Volta's tool-shim contract; not release-gated in this repository |
+| nvm | select Node 24+, then use the npm command | Guidance; globals belong to the selected Node installation |
+| fnm | select Node 24+, then use the npm command | Guidance; globals belong to the selected Node installation |
+| asdf | select Node 24+, then use the npm command | Guidance; globals belong to the selected Node installation |
+| pnpm | `pnpm add --global --ignore-scripts knodin@<version>` | Executable gate provided; release verification requires the published version |
+| Bun | `bun add --global --ignore-scripts knodin@<version>` | Executable gate provided; release verification requires the published version |
+| approved npm-compatible registry | use the npm command with approved registry configuration | Same artifact; registry authentication/promotion is organization-owned |
+| P&T GHES release asset | after migration, download the exact `.tgz` from `Enterprise-Apps/knodin`, verify SHA-256, then use the npm command with the local file | Planned knodin path; the legacy mirror remains authoritative until the external rename and release verification complete |
+| Homebrew | after migration, `brew install knowdin/tap/knodin` | Planned knodin path; the legacy tap remains authoritative until the external rename and formula gate complete |
+
+“Guidance” is not a compatibility claim. The repository records the manager
+version, command, package version, platform, and result when a release gate is
+actually run.
+
+The executable harness is `npm run test:package-managers -- npm pnpm bun`.
+Registry-backed release checks use
+`RECKON_SMOKE_PUBLISHED_VERSION=<version> npm run test:package-managers -- mise volta`;
+they intentionally refuse to substitute a local tarball for a published
+manager-owned tool.
+
+## Exact npm installation
+
+Node.js 24 or newer is required:
+
+```bash
+npm install --global --ignore-scripts knodin@0.4.3
+knodin --version
+knodin doctor
+```
+
+`0.4.3` is the version prepared by this change and becomes installable only
+after the separately authorized npm publication step. Replace it with the
+exact published release being deployed. Exact versions make
+rollbacks and manager comparisons reproducible. A bare `knodin` resolves
+the registry's `latest` tag and is less reproducible.
+
+The package does not use an install lifecycle script to detect package
+managers. It cannot intercept a package-manager command before it is installed,
+and a postinstall heuristic would neither fix PATH ownership nor prove which
+manager will execute the command later.
+
+knodin's verified CPU path does not require dependency lifecycle scripts.
+Preserve `--ignore-scripts`. The `boolean@3.2.0` warning is upstream transitive
+debt in the local embedding runtime, not a direct runtime call. The
+`check:dependency-deprecations` gate alerts when upstream movement makes removal
+safe; ineffective overrides are not shipped.
+
+## mise
+
+Use mise's npm backend so the executable is owned by one stable mise shim:
+
+```bash
+mise use --global npm:knodin@<version>
+mise which knodin
+knodin --version
+```
+
+The current mise npm backend uses an embedded installer by default, blocks
+unreviewed lifecycle scripts, and applies a low-download policy to an unlocked
+tool. A reviewed first install may require the package-specific
+`allow_low_downloads` setting; a locked tool does not. Do not disable the
+policy globally. knodin does not need lifecycle scripts.
+
+Verify the same shim both outside a repository and inside repositories that pin
+different Node versions:
+
+```bash
+mise which knodin
+knodin --version
+cd /path/to/node-24-project && knodin --version
+cd /path/to/node-26-project && knodin --version
+```
+
+## Volta
+
+Volta installs package binaries behind shims and pins each tool to the default
+Node engine in effect when the tool is installed:
+
+```bash
+volta install knodin@<version>
+volta which knodin
+knodin --version
+```
+
+Verify it inside a project with a different `volta.node` pin. The package tool
+should remain available with its own pinned engine. This repository labels
+Volta as guidance until that executable test is recorded for the release.
+
+## nvm, fnm, and asdf
+
+These managers select a Node installation. npm globals belong to that selected
+installation, so changing Node versions can make `knodin` disappear:
+
+```bash
+nvm use 24
+npm install --global --ignore-scripts knodin@<version>
+```
+
+Use the equivalent `fnm use` or `asdf` selection before installing. Install
+knodin for each Node version used by your repositories, use the manager's
+documented package-migration facility, or choose a manager-owned tool shim such
+as mise/Volta. nvm documents `--reinstall-packages-from` for migration.
+
+## pnpm and Bun
+
+Persistent global installs are:
+
+```bash
+pnpm add --global --ignore-scripts knodin@<version>
+bun add --global --ignore-scripts knodin@<version>
+```
+
+Confirm the manager's global binary directory is on PATH (`pnpm bin -g` or
+`bun pm bin -g`). Temporary runners such as `npx`, `pnpm dlx`, and `bunx` are
+not supported for initialized repositories because later hooks and MCP clients
+need a stable executable.
+
+## Approved npm-compatible registries
+
+Organizations may promote the unchanged npm artifact through an approved
+npm-compatible registry. Configure the registry and credentials through the
+package manager's normal user or CI configuration, never in this repository:
+
+```bash
+npm install --global --ignore-scripts knodin@<version>
+```
+
+Public/package documentation intentionally does not name internal registry
+hosts. `knodin doctor` reports the configured channel without printing
+credentials.
+
+P&T engineers without GitHub SaaS access should use the authenticated GHES
+release-asset procedure in
+[`PT-ACCESS-RECOMMENDATION.md`](PT-ACCESS-RECOMMENDATION.md). It installs the
+same digest-verified npm tarball without cloning source.
+
+## Homebrew
+
+knodin uses a Formula, not a Cask: it is an npm CLI and does not ship a
+standalone application bundle. The formula consumes the published npm tarball,
+verifies SHA-256, depends on Node, installs under Homebrew `libexec`, and
+disables unnecessary dependency scripts.
+
+After the external tap is renamed and certified, install from the public
+knodin tap:
+
+```bash
+brew install knowdin/tap/knodin
+```
+
+A version is not called Homebrew-supported until the corresponding published
+npm tarball passes version, MCP initialize/tools-list, `init`, `status`,
+`query`, `repair`, and uninstall smoke tests. The tap is
+`knowdin/homebrew-tap`; the formula and attached release evidence must
+identify the exact source commit and tarball digest.
+
+The planned knodin formula will be maintained in `knowdin/homebrew-tap`; that
+path is not represented as live by this code-only rename.
+The repository-local `packaging/homebrew/knodin.rb` is a historical
+candidate fixture and must not be promoted or used to certify a newer release.
+For a release gate, download the live tap's version-specific formula, verify its
+URL and digest against the exact release tarball, and pass that file explicitly
+to `scripts/homebrew-formula-smoke.sh`. The harness builds and installs the
+formula, runs the lifecycle test block, uninstalls it, and verifies Homebrew no
+longer owns the formula. It refuses to replace an existing installation.
+
+## Initialize, upgrade, and uninstall
+
+```bash
+knodin init
+knodin status --deep
+knodin doctor
+```
+
+Upgrade with the manager that owns the executable:
+
+```bash
+npm install --global --ignore-scripts knodin@<new-version>
+mise use --global npm:knodin@<new-version>
+volta install knodin@<new-version>
+brew update && brew upgrade knodin
+```
+
+Uninstall:
+
+```bash
+npm uninstall --global knodin
+mise uninstall npm:knodin
+volta uninstall knodin
+brew uninstall knodin
+```
+
+Uninstalling the package does not silently delete repository indexes or user
+configuration. Remove those explicitly only after reviewing their paths.

package/docs/MCP.md

@@ -0,0 +1,100 @@
+# MCP configuration and diagnostics
+
+knodin exposes exactly one MCP tool named `knodin`. Capabilities such as
+context, explain, review, search, docs, doctor, repositories, and systems are
+operations of that gateway, not separate top-level tools.
+
+## Choose a scope
+
+- **Personal:** `knodin init --scope personal` configures detected clients with
+  user-owned or excluded local files.
+- **Team:** `knodin init --scope team` writes merge-safe repository
+  configuration for supported clients. Commit only the intended files.
+- **CLI-only:** `knodin init --scope cli-only` keeps the local graph and Git
+  refresh behavior without MCP registration.
+
+knodin supports project adapters for Claude Code, Codex, Gemini CLI, and
+Antigravity. A generic MCP handshake is release-gated. Named-client status is
+reported only when its adapter/configuration is detected; it is not proof of
+every client version or platform.
+
+## Canonical command
+
+The server command is:
+
+```text
+knodin serve
+```
+
+Prefer this command when the client inherits the same PATH. If it does not,
+use the absolute stable shim reported by `knodin doctor`. A mise or Volta shim
+is preferable to a version-specific npm global path. nvm/fnm/asdf npm globals
+can change when the selected Node version changes.
+
+Manual JSON configuration:
+
+```json
+{
+  "mcpServers": {
+    "knodin": {
+      "command": "knodin",
+      "args": ["serve"]
+    }
+  }
+}
+```
+
+Codex TOML:
+
+```toml
+[mcp_servers."knodin"]
+command = "knodin"
+args = ["serve"]
+```
+
+## Compact structural responses
+
+Use `detailLevel: "compact"` for the Token Optimizer-style structural path:
+
+- `query` with `file_summary`, `batch_outline`, or `project_overview`;
+- `search` for normalized symbol-name discovery; or
+- `explain` with `includeSource: true` for exact symbol source.
+
+The response is a deterministic compact string. Its first line reports
+freshness and returned/total counts; result lines retain a stable `~` identity
+handle, symbol kind, nesting where applicable, and source location. Outline
+rows also retain a compact signature. An ambiguous explain begins with
+`ambiguous` and lists candidates instead of selecting one. A returned `~`
+handle may be supplied as `identity` on a later request; prefix collisions
+remain explicit ambiguity rather than becoming a guessed match.
+
+This mode intentionally omits unrelated graph fields, generic telemetry, and
+the normal response-budget envelope. `byteBudget` still acts as a hard UTF-8
+ceiling by removing complete result rows and updating the returned count. When
+the requested budget cannot fit even the truthful header, the result is empty
+rather than exceeding the caller's limit. The full structured response remains
+the default when `detailLevel` is omitted.
+
+## Real handshake diagnostics
+
+Run:
+
+```bash
+knodin doctor
+```
+
+Doctor resolves the executable/symlink chain, inspects duplicate candidates,
+reports configured client files, and sends real JSON-RPC `initialize` and
+`tools/list` requests. A healthy response identifies server
+`knodin` and exactly one tool named `knodin`.
+
+If the handshake fails:
+
+1. Run `command -v knodin` and `knodin --version` in the client's environment.
+2. Check `knodin doctor` for a version-manager-owned PATH or duplicate install.
+3. Re-run `knodin init` after changing the manager, Node version, or shim.
+4. Inspect client logs without copying tokens, source, or personal paths into
+   public reports.
+
+MCP requests never trigger update-network checks. Cached update state is
+available through the `doctor` operation without changing stdio framing.

package/docs/PT-ACCESS-RECOMMENDATION.md

@@ -0,0 +1,91 @@
+# P&T access through Docusign GitHub Enterprise Server
+
+The knodin GHES path is planned as
+`github.docusignhq.com/Enterprise-Apps/knodin`, but this repository rename does
+not create or verify that external repository. Until the mirror is renamed and
+its knodin artifact is certified, P&T engineers must use the existing legacy
+mirror and its documented release asset. `Enterprise-Apps` is a legacy
+namespace; product changes must continue to originate in the authoritative
+GitHub SaaS repository, not the downstream mirror.
+
+The legacy `v0.3.0` release and its original artifact digest were verified on
+2026-08-01. That evidence does not certify a renamed knodin artifact or path.
+
+## Quick install without GitHub SaaS
+
+Node.js 24 or newer and an authenticated GHES CLI are required. Download the
+versioned release asset from GHES, verify its observed SHA-256, install it
+without dependency lifecycle scripts, and initialize the existing checkout:
+
+```bash
+mkdir knodin-install && cd knodin-install
+GH_HOST=github.docusignhq.com gh release download v0.3.0 \
+  --repo Enterprise-Apps/reckon-graph \
+  --pattern 'reckon-graph-0.3.0.tgz'
+printf '%s  %s\n' \
+  373ca7540e745915f195e51f4ed6383374e4df4a2b8663872b2f279380e60989 \
+  reckon-graph-0.3.0.tgz | shasum -a 256 --check
+npm install --global --ignore-scripts ./reckon-graph-0.3.0.tgz
+cd /path/to/existing/repository
+reckon init
+reckon doctor
+reckon status --deep
+```
+
+Unverified Windows guidance: PowerShell provides
+`Get-FileHash -Algorithm SHA256` instead of `shasum`, and the npm/CLI commands
+are intended to be portable. A native Windows named-client run has not yet been
+certified, so this is not a Windows support claim. The release page records the
+versioned filename and observed digest; do not substitute a branch archive or a
+mutable `latest` URL. GHES does not currently enforce immutable releases, which
+is why digest verification and the separate signed-update trust remain
+required.
+
+The same 0.3.0 tarball was published to Docusign Artifactory at
+`dts-productivity-engineering-npm-dev-local/knodin-0.3.0.tgz`. That raw
+artifact path requires normal corporate Artifactory authentication and is not
+an npm registry endpoint. GHES release download is the supported P&T bootstrap
+until an approved internal npm virtual repository exposes the package metadata.
+
+## Mirror operating model
+
+1. Source commits and reviewed release tags originate in the GitHub SaaS
+   repository.
+2. The GHES `main` branch and release tag are synchronized without rewriting
+   history.
+3. The exact retained release tarball is attached to the matching GHES release;
+   it is not rebuilt on GHES.
+4. A release is not certified merely because it appears on GHES. The final
+   cross-channel attestation must prove that npm, Artifactory, GitHub SaaS,
+   Homebrew, and GHES represent the same source and bytes.
+5. Developers do not dual-push feature branches. Mirror synchronization is a
+   release/operations responsibility and must eventually use a narrowly scoped
+   workload identity rather than a personal SSH key.
+
+The destination must eventually enforce repository visibility, branch
+protection, required reviews/checks, security scans, commit/tag provenance, and
+license notices. Today the repository is internal, but `main` is unprotected and
+maintainers retain push access. Those are open governance controls, not
+completed evidence. Future mirror automation must fail closed and must not
+accept changes back into the authoritative repository.
+
+## Required governance follow-up
+
+Record or complete:
+
+- repository-owner approval to disclose the source to P&T;
+- enterprise GitHub/security approval for cross-organization private forks or
+  mirrors;
+- legal/compliance confirmation for source and license visibility;
+- the exact destination GitHub organization and repository name;
+- confirmation of destination visibility and membership controls;
+- the required branch-protection, review, scan, and retention policy;
+- approval of a narrowly scoped GitHub App/workload identity, its installation
+  owners, secret store, rotation owner, and audit-log owner;
+- an owner for incident response and mirror decommissioning.
+
+The destination repository and current release asset are live. Branch
+protection, enforced read-only direction, automated mirror synchronization,
+production threshold-update trust, timed onboarding evidence, and a Windows
+named-client release certification remain open gates; the existence of this
+access path is not evidence that those separate controls are complete.

package/docs/RELEASE-0.3-EVIDENCE.md

@@ -0,0 +1,73 @@
+# Reckon Graph 0.3 evidence ledger
+
+This ledger freezes the field and competitor evidence used to define the 0.3
+release. Historical observations are not rewritten as current measurements.
+
+## Minions field observation
+
+The prior 0.1.22 field run recorded:
+
+- 3,006 source files;
+- 2,949 indexed files and 157 health findings before repair;
+- 3,006 indexed files after repair;
+- current HEAD `cbf058aa...`;
+- recorded indexed HEAD `4d45fe02...`;
+- a 16-commit distance while 0.2.0 status incorrectly reported healthy;
+- 195 repair operations, including reconciliation of stale/orphaned state and
+  regeneration of 1,874 symbol embeddings.
+
+The workload fast-forwarded main across 15 merged commits and removed 16 linked
+worktrees. The checked-in lifecycle regression recreates those lifecycle
+shapes, including additions, edits, renames, deletions, policy transitions,
+overlapping hook workers, immediate queries, and cleanup.
+
+The Minions checkout is a read-only field fixture for this release. Its current
+HEAD on 2026-07-30 was `44c91f6d013fd8d6f4e106d063a87eab94b19866`;
+the historical SHAs above belong to the original observation, not that later
+checkout state. Existing modified and untracked Minions files were left intact.
+
+## Token Optimizer observation
+
+The complete 102.8-second demo artifact has SHA-256
+`a8085ec26d56ab220f3b31578f818a911caf277e604ed9f8d46c0d9f31fbb60d`.
+It demonstrates seven named surfaces: file outline, symbol extraction, symbol
+find, batch outline, project overview, output compression, and command running.
+It describes Python AST parsing and heuristic/regular-expression coverage for
+other languages.
+
+At release time, no authorized immutable source commit, packaged executable,
+README, version, or raw measurement data was available, so the original
+observation was `demo-only`. A post-release source audit now pins the authorized
+GHES implementation at
+`a2b9cef5efdfcf0393e9e7a5ded229ffd9f613d7`. It verifies the source inventory
+and selected implementation observations, including a behavioral compression
+budget probe. Equivalent end-to-end measurements remain incomplete, and the
+displayed savings remain hypotheses: the demo showed two calls, used a bytes/4
+token estimate, and showed inconsistent 83% and 93% targeted-lookup figures.
+
+The reproducible comparison contract is
+[`../benchmarks/evaluations/token-optimizer-20260730/comparison-manifest.json`](../benchmarks/evaluations/token-optimizer-20260730/comparison-manifest.json).
+The immutable source result is
+[`../benchmarks/evaluations/token-optimizer-20260730/raw-source-audit-20260730.json`](../benchmarks/evaluations/token-optimizer-20260730/raw-source-audit-20260730.json).
+Missing behavioral measurements are `null`, never zero.
+
+The later C56 replay now executes all seven pinned workflows with shared
+fixtures, real-token counts, 20 warm samples, five cold-process samples, and
+explicit correctness oracles. Both products pass the five structural oracles.
+The result is intentionally `complete-with-gaps`: Token Optimizer is smaller
+and faster on all five small-fixture structural calls, Reckon has no output
+compressor yet, and command execution remains containment-gated. See
+[`../benchmarks/evaluations/token-optimizer-20260730/summary.md`](../benchmarks/evaluations/token-optimizer-20260730/summary.md).
+
+## Implemented and deferred
+
+Reckon now provides parser-grounded bounded file and batch outlines, compact
+source-only extraction, deterministic project overview, natural-prompt routing,
+real-token local telemetry, and a static local report through the existing
+single `reckon` gateway.
+
+`reckon run` is not shipped. A no-shell launcher alone could not prove portable
+hard memory limits and process-tree termination across POSIX and Windows. The
+full gate and adversarial fixtures remain documented in
+[`COMMAND-OUTPUT-COMPRESSION.md`](COMMAND-OUTPUT-COMPRESSION.md). This is a
+security decision, not a claim that the competitor implementation is unsafe.

package/docs/REPOSITORIES-AND-WORKTREES.md

@@ -0,0 +1,81 @@
+# Repositories and worktrees
+
+`repos` manages local repository checkouts operationally. It does not declare
+that discovered repositories form one software system.
+
+```bash
+knodin repos discover <root...> --depth 4 --linked-worktrees=skip
+knodin repos init <root...> --dry-run
+knodin repos status <root...>
+knodin repos doctor <root...>
+knodin repos search "payment adapter" --root <root> --items 25 --tokens 16384 --json
+```
+
+Use `--linked-worktrees=include` explicitly to include linked worktrees.
+Discovery is deterministic, bounded by depth, does not follow child symlinks,
+and does not prune Git metadata.
+
+Results distinguish:
+
+- a Git main worktree;
+- a Git linked worktree owned by that repository;
+- a repository nested inside another checkout;
+- stale linked-worktree metadata;
+- an unrelated repository under the same discovery root.
+
+Sibling location never establishes system membership or a relationship.
+`repos init` works sequentially and performs each live repository operation in
+a disposable process with a 768 MiB RSS ceiling. A worker that exceeds the
+ceiling or its deadline has its process group terminated, produces a
+repository-scoped failure, and does not prevent later repositories from being
+processed. JSON records the observed per-repository peak, enforced ceiling,
+and count of ceiling failures. The 50 ms RSS heartbeat is a bounded enforcement
+interval rather than a claim that transient allocation can never overshoot by
+one sample. Windows can terminate the worker process but cannot provide the
+same descendant process-group guarantee as macOS/Linux.
+
+Initialization supports `--dry-run` and preserves a healthy graph when only
+managed integration needs refreshing. Dry-run never starts a worker, opens a
+graph database, or loads a model. JSON output is versioned and never contains
+progress or deprecation messages.
+
+For large initialization runs, add `--manifest <path>`. knodin atomically
+records each completed repository after it succeeds. Repeating the identical
+command with the same manifest skips completed repositories and resumes the
+remaining deterministic sequence. A manifest is rejected if its repository
+selection, depth, or linked-worktree policy differs. `--dry-run` never writes
+the manifest. The single MCP gateway exposes equivalent `dryRun` and
+`manifestPath` arguments on `repositoryAction: "init"`.
+
+`knodin fleet init` is a deprecated compatibility alias for two minor releases.
+Its warning is written only for human output, never JSON/JSONL or MCP stdio.
+
+Repository inventory is portfolio health, not semantic federation. Configure
+cooperating components explicitly in `reckon.yaml`; use
+`knodin system validate` before system-scoped queries.
+
+## Independent repository search
+
+`repos search` visits selected repositories sequentially, never establishes
+system membership, and never uses the legacy semantic-federation peer list. Use
+repeatable `--include <stable-id-or-path>` and `--exclude
+<stable-id-or-path>` filters. Results retain repository-scoped symbol/file
+identity, exact source evidence, confidence, graph freshness, and health.
+
+The default is fail closed: an uninitialized, empty, indexing,
+repair-required, lifecycle-degraded, or unknown selected graph makes the
+answer `unavailable`, not an ordinary zero-match result. `--allow-partial`
+returns `partial` and names every omitted repository and remediation. A healthy
+search with no matches is `no-match`.
+
+`--items`, `--bytes`, and `--tokens` are hard response budgets. A truncated
+response includes an opaque `--cursor` value for deterministic continuation.
+The cursor is bound to the query and stable selection and is rejected if reused
+for a different search.
+
+Versioned inventory records include stable identity, checkout classification,
+initialization and health, HEAD/index freshness, languages, package identities,
+configured system memberships, bounded documentation candidates, errors, and
+remediation. Local paths are personal output; team configuration contains only
+stable identities. A roadmap filename is only a candidate unless team
+configuration declares authority.