I1966

What it is

Objective

Stop docs/generated/graph.json from silently dropping nodes and edges at the MAX_NODES cap. Either the cap is raised or removed under a measured size budget, or generation refuses a truncated graph and names the count and the cap. The committed graph must never be a prefix of the repository that still passes as whole.

Why

graph::Builder::node refuses every node past MAX_NODES = 2000 (apps/majordomus-cli/src/graph.rs). It sets metadata.truncated, and compose() then drops each edge whose end could not be added. generate::graph_document refuses an unresolved relation (ADR 0020, case 390) but writes a truncated graph without a word. derive-check stays green, and every newly indexed object takes the place of a real node and its edges. This is the defect case 390 was written against, 'the file looks whole and is quietly short of one edge', reached by another route. It also breaks the capability-graph milestone's criterion that a relation that does not resolve fails generation rather than going missing.

Now

The committed docs/generated/graph.json is composed without a node bound (graph::composed_complete, 9f98133aa2, PR #788) and holds 2434 nodes and 5341 edges with metadata.truncated false in 2,766,504 bytes; the implemented_by edge from majordomus://claim/mcp-uri-resolution to apps/majordomus-cli/src/capability/builtin/objects.rs is present. graph::whole refuses a truncated graph committed as data, and the site's why and product graphs go through it, proved by unit tests in graph.rs. Still open: no case drives generation over a fixture past a bound, because the composed graph has none, and no measured size budget is written beside MAX_NODES (2000, the bound of a graph a person is shown). Measured on master 4090b2b8ae, 2026-10-08.

Wanted

A committed graph.json is either complete, with metadata.truncated false, or it is not written: generation fails, naming the node count it needed and the cap it hit, as graph_document already does for an unresolved relation. If the cap is raised or removed for the committed artifact, the new bound is a size budget measured on this repository and written beside the constant with its measurement. The Cockpit and the interactive views may keep a display bound of their own, and they keep saying when they apply it.

Done when

unknown: the record declares no `completion`

Risk

Raising the cap without a budget brings the problem back one size later, and graph.json is already 2.3 MB. Refusing outright makes every derive fail until the bound is settled, so the refusal and the new bound belong in one change.

Acceptance

Scope

Touches

apps/majordomus-cli/src/graph.rsapps/majordomus-cli/src/generate.rstest/cases/390_unresolved_relation_refuses_generation.shdocs/generated/graph.jsondocs/generated/graph.schema.json

Not

The mesh registry's own MAX_NODES (apps/majordomus-cli/src/mesh/registry.rs), which is an unrelated bound on peersThe Cockpit's graph pages and the site's why-graph and product-graph, apart from keeping their existing truncation notice trueChanging which objects, claims or relations are composed: the inputs stay as they are, and only the completeness of the output is at stakePruning claims or index classes to get under the cap

Depends on

unknown: the record declares no `depends_on`

Priority

p1

Profile

implementation

Parallel safe

true

Owner

unknown: the record declares no `owner`

The work so far

Synchronisation

Adapter

scripts/github-sync

Repository

unknown: the derived plan's header carries no repository

External issue

unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

State there

unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

Findings

Nothing is wrong with these records.