@ybotok/loam 0.2.0-alpha.1 → 0.2.0-alpha.4

package/CHANGELOG.md

@@ -10,6 +10,171 @@ case for a change — the alternative that was rejected, the defect it came from
 generalises — lives where it is maintained: [SCHEMA.md](SCHEMA.md) for the rule,
 [ROADMAP.md](ROADMAP.md) for the priority and its exit criteria, and the commit that landed it._
 
+## [0.2.0-alpha.4] - 2026-09-03
+
+The view title becomes the subsystem's path. `0.2.0-alpha.3` was tagged and **never published** — it
+was withdrawn before its publish step for a reason unrelated to the code — so this is the release
+that carries both it and the entry below, and `npm i @ybotok/loam@alpha` moves from `0.2.0-alpha.2`
+straight to this one. A repo upgrading from either reports one `subsystem.views-stale` until one
+`loam subsystem sync`.
+
+### Changed — a generated subsystem view is titled by its path
+
+`0.2.0-alpha.3` gave each view the subsystem's own label. It now carries the whole path — every
+marked ancestor's label and its own, joined with ` / `, so `services/platform/order-flow` reads
+`Platform / Order flow`. Measured against the pinned likec4: the renderer reads that as a folder
+path, so the view list mirrors the directory tree a human already navigates — one folder per
+ancestor, the leaf's own label as the title — and two subsystems whose labels are equal are told
+apart by their parents instead of appearing twice under one name. The box a view draws keeps the
+subsystem's own label, unprefixed.
+
+Because loam is now the one composing with `/`, it owns what a `/` inside an authored label would
+do: measured, LikeC4 would show only the last segment and add a folder level the tree does not have,
+so a slash in a marker's `title` becomes `∕` (U+2215) and the whole authored label stays visible as
+one folder name. The alternative — a fixed `loam subsystems /` prefix — bought the same folder
+without the churn and put loam's own name in a reader's UI; the tree's own words won.
+
+Two costs, both real: the generated bytes move again, so a repo upgrading from `0.2.0-alpha.3`
+reports one `subsystem.views-stale` until one `loam subsystem sync`; and renaming a PARENT's title
+now rewrites the bytes of every view beneath it.
+
+## [0.2.0-alpha.3] - 2026-09-03
+
+The generated subsystem views, made readable — and the defect that hunt found underneath them.
+Still a prerelease on the `alpha` line: `npm i @ybotok/loam@alpha` installs it. Nothing below is
+breaking, and one entry is a change every repo NOTICES: the generated file's bytes move, so the
+first `loam validate --all` after upgrading asks for one `loam subsystem sync`.
+
+### Fixed — a `subsystem.views-stale` no command could clear
+
+`loam validate --all` grades `architecture/subsystems.likec4` against the whole `architecture/`
+project — the landscape merged with every `architecture/usecases/*.likec4` — while `loam subsystem
+sync` and the write verbs rendered it from `landscape.likec4` alone. One use-case document declaring
+an element bound to a filed service was therefore enough to make `sync` answer `current` while
+`validate --all` exited 1 with `subsystem.views-stale`, whose message names `sync` as the repair.
+Reproduced on `examples/docs`; the two now read the same documents. No code, flag or payload key
+changes.
+
+### Changed — the generated subsystem views carry a label and a boundary
+
+`architecture/subsystems.likec4` exists only to be rendered, and in the renderer its views were the
+least readable objects in a docs repo: no title, so LikeC4 showed the hex-escaped id
+(`subsystem_platform__order_2dflow`), and leaf includes only, so a fleet drawn as ordinary
+grouped C4 rendered flat. Every view now carries `title` (the marker's, or the directory name) and
+`description` when the marker authors one, and draws a boundary: the model's own containing element
+when one holds exactly the subsystem's members, a `group '<title>'` mirroring the directory subtree
+when the landscape nests nothing, and — when the members are nested but no element owns exactly them
+— no box plus one comment line, `// model: no boundary — …`, which is loam's whole answer to a tree
+and a map that disagree. Nothing grades that comment: placement still carries no policy.
+
+Marker text is normalized to one line and escaped before it is written (measured: a raw `'` in a
+title is two parse errors and blanks the fleet's whole map in the renderer; `Ops' } view evil {` is
+zero errors and injects a view). [SCHEMA.md](SCHEMA.md) states the rules.
+
+What a repo notices, and what it costs:
+
+- the first `loam validate --all` after upgrading reports exactly one `subsystem.views-stale` error
+  (exit 1) until one `loam subsystem sync` runs. `sync` does not `git add`, so the repair leaves one
+  unstaged one-file diff to commit;
+- the boundary depends on which OTHER services sit under an element, so an unrelated adoption or
+  archive can flip a view from boxed to flat and restale the file. `loam archive` now withholds its
+  "living spec + landscape are now complete + current" line, prints one warning naming
+  `loam subsystem sync`, and adds `subsystemViewsStale: true` to its `--json` payload when it left
+  the file behind;
+- `subsystem.views-stale` and `subsystem.view-id-collision` now carry `locations`: the generated
+  file (or `architecture/` when it does not exist yet) and the claimant document respectively. Both
+  used to fall back to the landscape, sending an editor to a file with nothing to fix in it.
+
+No command, flag, exit code, envelope key or stable code string changes; `subsystem.views-stale` is
+not in the `IssueCode` union and carries no `gates` key, so `loam archive` remains unaffected by it.
+
+## [0.2.0-alpha.2] - 2026-09-02
+
+The deployment axis, and the two defects the axis surfaced on its way in. Still a prerelease on the
+`alpha` line: `npm i @ybotok/loam@alpha` installs it. Nothing below is breaking, but two entries are
+changes a repo can NOTICE — a fleet that had already placed a `#obl-` tag on a `deploymentNode`
+starts seeing findings it was never shown, and `loam status` stops asking an architecture-only
+feature for a business spec.
+
+### Added — the deployment axis: topology joined to requirements
+
+A LikeC4 `deployment { }` block has always been legal in a docs repo and was completely unread. The
+parser resolved every `instanceOf`, and after that no requirement could name a node, no `#obl-` tag
+on a datacenter was graded, and the context pack an agent implements from did not mention topology
+at all. Five things change, and a fleet that draws no topology is unaffected by every one of them —
+the axis opts in on the block's existence, the way the obligation vocabulary opts in on its file.
+
+- **`Covers:` gains a fourth entry form.** `node:<id>` names a deployment node or an instance, and
+  `node:a -> node:b` names an edge between them; both match literally. This is the form that lets an
+  architecture requirement about replication name the two clusters it is written about, and a
+  topology change that renames one now reports `covers.unknown` with the real ids offered — spelled
+  with the prefix, because that is the line the author has to type. Both sides of an edge carry the
+  prefix or neither; a bare id stays an element entry.
+- **An obligation on a deployment object is graded.** `obligation.unknown`, `obligation.unapplied`
+  and `obligation.uncovered` now walk the topology as well as the logical model. This is a
+  behaviour change a repo can notice: a `#obl-` tag on a `deploymentNode` used to be invisible to
+  every check, so a fleet that had placed one starts seeing findings it was never shown. A
+  datacenter is owned by no service, so `obligation.uncovered` drops `subject` there and names the
+  requirement's home in general terms rather than picking a team.
+- **A feature can bring topology.** `features/<FEAT>/deployment/<name>.likec4` is a create-only
+  document `loam archive` copies into `architecture/` and `loam unarchive` takes back — the third
+  whole-file slot, beside `usecases/` and `glossary/`. Say `extend` in it to add to a region the
+  living map already declares; two features may extend one region from documents of their own and
+  both archive. Two new codes, both errors and neither overridable: **`deployment.doc-exists`** when
+  the feature's document names a file the living tree already holds, and **`deployment.doc-invalid`**
+  when it cannot be read against the map the feature's own merge would leave behind. The second is
+  what makes the ordinary case legal — a document instancing a service only this feature's
+  `delta.likec4` adds resolves, because the corpus inside a feature window is feature ∪ living — and
+  refuses the case where the merge does not land what the document names. `delta.likec4` still
+  refuses a `deployment { }` block and now names this slot instead of the living landscape.
+  A third, **`deployment.doc-reserved`**, refuses a name loam owns inside `architecture/` —
+  `subsystems.likec4`, `landscape.likec4`, or a path under `usecases/` — whether or not the target
+  exists, because two of the three fail silently when it does not: nothing parses the generated
+  subsystem views and `loam subsystem sync` overwrites them wholesale.
+- **`loam context` carries the topology.** `--json` gains `living.deployment` — the service's
+  instances, and the deployment edges touching them from either end.
+- **One more statement in the adoption brief's unchecked list**, now sixteen: nothing here knows
+  whether the second cluster exists, is reachable, or holds the data a requirement claims, and no
+  check counts datacenters — how many a service needs is a decision the fleet writes down as a
+  requirement, never one loam evaluates.
+
+### Fixed — the never-overridable archive refusal names what actually refused
+
+It said `N element binding(s) name an illegal service id` for every code in that register, and had
+done since the use-case slot put a second one there — about features that bind nothing. The headline
+now counts the refusals and the closing line names their codes; each issue keeps its own sentence.
+The `--json` envelope is unchanged: consumers branch on `issues[].code` and `overridable`, which is
+what that split exists for.
+
+### Fixed — `loam status` no longer invents work for an architecture-only feature
+
+A feature whose only requirement delta is `specs/<svc>/arch.spec.md` reported two things that were
+not true, and both are corrected. The `spec` row read `missing` and `next.author-spec` told the
+author to write business requirements the change does not have — while `loam validate --feature`
+accepted the same tree at exit 0 and `coherence`'s `service.no-requirement-delta` stayed silent,
+because every other reader counts the service DIRECTORY and not which corpus is in it. And the
+`verification` row read `blocked` with `blockedBy: ["delta", "spec", "openapi", "asyncapi"]`,
+telling the reader there was nothing to derive a checklist from — while `featureChecklist` reads
+`arch.spec.md` and `loam verify` on that feature returns a real checklist.
+
+The fleet form carried the same defect independently, and it broke the rule stated one line below
+it in its own source: `loam status` with no feature reported `missing <svc>/spec` and staged the
+feature `missing`, over a feature `loam status <FEAT>` called `ready`. Both forms now accept either
+corpus as the service's requirement delta, and `<svc>/spec` is named only when neither exists.
+
+Three payload-visible consequences, all in `loam status --json`: `artifacts[]`'s `spec` row is
+`required: false` when the service's `arch.spec.md` delta exists (it was unconditionally `true`),
+`arch-spec` now counts as a verification feeder, so `blockedBy` gained `"arch-spec"` in the
+one case that is still genuinely blocked — a feature with no requirement delta of either kind —
+and `features[]`'s `missing` and `stage` no longer report an architecture-only feature as
+incomplete. No finding code, flag or exit code changes. This is the change to read if a script
+branched on `artifacts[].required` or on `features[].missing`.
+
+The case is the one `arch.spec.md` exists for: an outbox, a retry policy, an alert — obligations no
+business scenario was ever going to carry, so the feature that adds one has no business requirement
+to write. Found by authoring loam's own architecture change through loam's own lifecycle, which is
+the trigger ROADMAP's self-hosting section records for that axis.
+
 ## [0.2.0-alpha.1] - 2026-09-01
 
 The first release of the 0.2 line, and the whole accumulated body since `0.1.0-beta.3` — 116

package/README.md

@@ -7,7 +7,7 @@
 [![CI](https://github.com/ybotok/loam/actions/workflows/ci.yml/badge.svg)](https://github.com/ybotok/loam/actions/workflows/ci.yml)
 [![npm](https://img.shields.io/npm/v/@ybotok/loam.svg)](https://www.npmjs.com/package/@ybotok/loam)
 
-> **Pre-release: `0.2.0-alpha.1`**, the first release of the 0.2 line and the newest published
+> **Pre-release: `0.2.0-alpha.4`**, the third published release of the 0.2 line and the newest published
 > version of [`@ybotok/loam`](https://www.npmjs.com/package/@ybotok/loam). It publishes under the
 > `alpha` npm dist-tag: `npm i @ybotok/loam@alpha`, or the exact version, always installs this
 > line. `latest` is moved onto a release by hand once it has published, so a plain
@@ -108,7 +108,7 @@ both halves are written down: the question in the brief or the checklist, the an
 
 Most of this category will tell you what it checks. loam ships the other list too, in the binary:
 **[`src/core/brief/unchecked.ts`](https://github.com/ybotok/loam/blob/main/src/core/brief/unchecked.ts)
-is fifteen statements of what no check will ever tell you**, printed into the adoption brief beside
+is sixteen statements of what no check will ever tell you**, printed into the adoption brief beside
 the checks that do run. It says, in loam's own words, that nothing here knows whether the model is
 the architecture the code actually has, whether a requirement is *true*, whether an `operationId` is
 the one the code serves, or whether `sources` names the files anybody read. And it says the one that
@@ -358,7 +358,7 @@ cannot hold.
 | `loam new <FEAT>` | `--title <text>` `--touches <id>` `--new-service <id>` `--capability <id>` | Scaffold a feature: intent, C4 delta, a requirement delta per service named by `--touches`/`--new-service`, and a capability delta per promise named by `--capability` (all repeatable) |
 | `loam show <service\|FEAT>` | `--type <kind>` | Everything loam knows about one service or feature. A feature's JSON includes a semantic `review` pack: intent, exact architecture objects, API/event slices, dependencies, artifacts, verification, blockers and next actions. `--type` forces an ambiguous reading |
 | `loam subsystem <verb> [names...]` | `--into <name>` `--under <name>` `--title <text>` `--description <text>` `--owner <name>` | Manage the grouping tree under `services/` — a navigable tree no identity depends on. `new`/`rm`, `move … --into`, `rename`, `list`, `history`, `sync` |
-| `loam adopt` | `--service <id>` `--subsystem <name>` `--targets` | Brief an agent to write this service's baseline into the docs repo as `draft`: the target paths, the grammar of each, what the landscape already says, and the checks that follow. Writes nothing. `--targets` narrows it to what varies by service — the walk, the 37 checks and the fifteen statements of what nothing checks are the same bytes everywhere, so a `full` field names the one run that carries them: 42,873 bytes to 17,805 |
+| `loam adopt` | `--service <id>` `--subsystem <name>` `--targets` | Brief an agent to write this service's baseline into the docs repo as `draft`: the target paths, the grammar of each, what the landscape already says, and the checks that follow. Writes nothing. `--targets` narrows it to what varies by service — the walk, the 37 checks and the sixteen statements of what nothing checks are the same bytes everywhere, so a `full` field names the one run that carries them: 42,873 bytes to 17,805 |
 | `loam delta <FEAT>` | `--service <id>` | Project a feature onto one service: the intent, its requirement deltas with every body and Given/When/Then line verbatim, the endpoints it adds or retires, and the edges around it. Doubles as a coding-agent task |
 | `loam gherkin [<FEAT>]` | `--service <id>` `--dry-run` | Emit spec scenarios as digest-stamped Gherkin `.feature` files into the service repo's `<gherkinDir>/loam/` |
 | `loam rebase [<FEAT>]` | `--service <id>` `--dry-run` `--living` | Pin the feature to the living versions it was written against, on the requirement axis and the contract axis. `--living` takes no feature: it pins the living corpus's `Realizes:` entries to the capability requirements they name, which is what makes `capability.realizes-stale` able to fire later |
@@ -486,7 +486,7 @@ always preserved byte for byte, with the entry printed for manual merge.
   maps, what is lost, what must be added.
 - [ROADMAP.md](ROADMAP.md) — the evidence-backed improvement plan, priorities, non-goals and exit
   criteria.
-- [CHANGELOG.md](CHANGELOG.md) — released beta.1–alpha.1 plus the changes on `main` under
+- [CHANGELOG.md](CHANGELOG.md) — released beta.1–alpha.4 plus the changes on `main` under
   `[Unreleased]`.
 - [docs/BENCHMARKS.md](https://github.com/ybotok/loam/blob/main/docs/BENCHMARKS.md) — what a
   fleet-sized run costs, with the method, the machine and the committed runs behind every number.
@@ -522,12 +522,12 @@ authored-capability axes with the `Realizes:` join, use cases graded as `dynamic
 `architecture/obligations.yaml` architectural obligations checked through `#obl-` tags and
 `Covers:`. Known limits, each with its owner in [ROADMAP.md](ROADMAP.md): the complete gate still
 needs repeatable CI and installed-package evidence observed from an actual push. Speculative
-`render`, health composition and UI generation come later. Behind that status stand **156 test files** (counted 2026-09-01): the count is graded
+`render`, health composition and UI generation come later. Behind that status stand **157 test files** (counted 2026-09-02): the count is graded
 against a live readdir by `test/docs-facts.test.ts`, so this sentence fails the suite the moment it
 trails the tree.
 
 The package is published as [`@ybotok/loam`](https://www.npmjs.com/package/@ybotok/loam), currently
-`0.2.0-alpha.1`: the unscoped `loam` name is taken by an unrelated GDAL wrapper, so the package ships
+`0.2.0-alpha.4`: the unscoped `loam` name is taken by an unrelated GDAL wrapper, so the package ships
 under the maintainer's own npm user scope. Releases are tag-driven and maintainer-only
 ([CONTRIBUTING.md](CONTRIBUTING.md)); the version this line names is pinned to `package.json` by a
 drift test, so it cannot silently trail a release.

package/ROADMAP.md

@@ -1,6 +1,6 @@
 # Roadmap
 
-_Assessed 2026-08-28._
+_Assessed 2026-09-03._
 
 This is loam's canonical improvement sequence. It records priorities and exit criteria, not delivery
 dates. An item is complete only when its exit criteria are supported by repeatable evidence; moving
@@ -18,20 +18,21 @@ acceptance tests, and implementation evidence remain ordinary files in repositor
 state inside a service. The CLI is small enough to audit, and every writer — not only archive — now
 commits through a locked, journaled transaction that a crash cannot leave half-applied.
 
-The tree contains **419 TypeScript modules in 128 source packages**, with an acyclic package graph
+The tree contains **427 TypeScript modules in 130 source packages**, with an acyclic package graph
 checked by
 [scripts/package-graph.mjs](https://github.com/ybotok/loam/blob/main/scripts/package-graph.mjs). The
 CLI exposes **29 commands** from [src/cli.ts](https://github.com/ybotok/loam/blob/main/src/cli.ts),
-and the suite stands at **156 test files**. Those four counts are deliberately stated OUTSIDE the
+and the suite stands at **157 test files**. Those four counts are deliberately stated OUTSIDE the
 dated snapshot below: each derives from the tree in one readdir, so
 [test/docs-facts.test.ts](https://github.com/ybotok/loam/blob/main/test/docs-facts.test.ts) grades
 them live and this paragraph cannot quietly trail the code the way its predecessor did.
 
-_Measured 2026-08-31 on `ab4c856` plus the changes on top of it, and dated because neither number
-has a cheap derivation:_ lint, typecheck, `npm run arch:check` and `npm run meta:check` green;
-`npm test` passing **3,358/3,358 tests**, with two `skipIf(asRoot)` cases the root gate container
-cannot run; and the coverage gate passing with **92.20% statements, 83.97% branches, 96.75%
-functions, and 94.13% lines** against its thresholds of 91 / 82 / 95 / 93.
+_Measured 2026-09-03 at `0.2.0-alpha.4`, and dated because neither number has a cheap derivation:_
+lint, typecheck, `npm run arch:check` and `npm run meta:check` green; `npm test` passing
+**3,410/3,410 tests**, with two `skipIf(asRoot)` cases the root gate container cannot run; the
+coverage gate passing with **92.26% statements, 84.06% branches, 96.62% functions, and 94.20%
+lines** against its thresholds of 91 / 82 / 95 / 93; and `npm run release:check` plus
+`npm run test:package` green against the real tarball.
 
 One qualification remains, and it is observation rather than code: nothing has been pushed since the
 CI `stability` job and the tarball-reading package smoke landed, so repeatable CI executions — the
@@ -98,14 +99,16 @@ The strongest foundations to preserve are:
 ## Now
 
 Nothing is queued behind code. Every integrity, enforcement and lifecycle item that preceded this
-has landed (see [Recently landed](#recently-landed)) — the authored business axis and, with the three
-entries at the top of that section, the use-case axis too. The axis is now writable through the
-change lifecycle, and the gate and the report agree about what it contains.
+has landed (see [Recently landed](#recently-landed)) — the authored business axis, the use-case
+axis, and as of 2026-09-02 the deployment axis, which is the first item this file ever wrote
+directly into this section rather than promoting from [Later](#later--promote-only-from-evidence).
 
-What is left is the one thing this file cannot close by writing code, and it stays where it is
-rather than being promoted here for the shape of it: the CI `stability` job and the installed-package
-smoke have still to be OBSERVED green from a pushed commit. That is release evidence to collect, not
-an improvement to make.
+### Release evidence, unchanged
+
+What is left is the one thing this file cannot close by writing code, and it stays
+where it is rather than being promoted for the shape of it: the CI `stability` job and the
+installed-package smoke have still to be OBSERVED green from a pushed commit. That is release
+evidence to collect, not an improvement to make.
 
 An item returns to this section from [Later](#later--promote-only-from-evidence) when fleet evidence
 names its operator, repeated task, failure mode, frequency, current workaround and measurable
@@ -122,6 +125,125 @@ changes, exit criteria, and what each review surfaced — are in this file's his
 working tree and not committed, and the range goes in with the commit rather than being guessed at
 here.
 
+#### The generated subsystem views — a label, a boundary, and one reader of the map
+
+**Landed 2026-09-03.** Three problem reports from a fleet running loam, one axis. The generated
+`architecture/subsystems.likec4` exists only to be rendered and was the least readable object in a
+docs repo: no `title`, so the renderer showed the hex-escaped view id, and leaf includes only, so a
+fleet drawn as grouped C4 rendered flat. Each view now carries the marker's title (the directory
+name when it has none) and description, and draws a boundary the LANDSCAPE decides: the model's own
+containing element when one holds exactly the members, a `group` mirroring the directory subtree
+when the map nests nothing, and one `// model: no boundary — …` comment when the two disagree.
+That comment is the whole answer to the drift the third report asked about — disclosure in a
+generated artifact, never a finding, because grading placement against the map is the policy the
+tree is defined not to carry. The graded alternative is written down under
+[Later](#later--promote-only-from-evidence) with the evidence bar it has to clear.
+
+The hunt found what neither report did: `validate --all` graded that file against the whole
+`architecture/` project while every writer rendered it from `landscape.likec4` alone, so a
+use-case document binding one element could produce a `subsystem.views-stale` that
+`loam subsystem sync` reported as `current` — reproduced on `examples/docs`, and fixed by pointing
+both sides at the same read.
+
+#### The deployment axis — topology joined to requirements
+
+**Promoted 2026-09-02, and authored as a feature in loam's own docs repo** rather than as an item
+text here: `meta/docs/features/archive/FEAT-1-the-deployment-axis/`, whose `intent.md` carries the
+four measurements and whose `specs/loam/arch.spec.md` carries the five rules the change establishes,
+each with scenarios. This entry is the decision and the gate; that feature is the specification, and
+the two must not be allowed to become two accounts of the same change.
+
+**Landed 2026-09-02, complete.** Every step is in, and step 4 was corrected rather than built
+(below) — the item specified two finding codes that the implementation showed it should not mint.
+FEAT-1 archived once every edge it claimed existed —
+and it archived having been CORRECTED against the tree twice, which is the argument for the route
+rather than a footnote to it: the delta predicted a `core/kernel/` dependency that turned out to be
+type-only (a brand costs an annotation, not an import) and missed `core/coherence/` entirely.
+`npm run meta:check` was red for the whole of the build and went green with the archive, which is
+the axis working rather than a gap in it.
+
+The whole change is reviewable as five commits on `feat/deployment-axis`, and the one thing to read
+first is what the implementation taught the plan: two of the codes this item specified were not
+minted, and the reasons are in step 4.
+
+**What is wrong today.** A LikeC4 `deployment { }` block is legal in a docs repo and completely
+unread. The parser resolves every `instanceOf` in it — a container renamed out from under a
+deployment node fails the gate as `landscape.invalid` — and after that nothing: no requirement can
+name a node, no report counts one, and the context pack an agent implements from does not mention
+topology at all. Two of the four measurements taken on a copy of `examples/docs` are the reason this
+is an item rather than a wish. A `#obl-` tag on a `deploymentNode` is invisible to
+`validate/fleet/obligations.ts`, which walks the logical model only — the same undeclared tag raises
+`obligation.unknown` on a container and nothing on a datacenter, which is fail-open and a defect on
+its own terms. And `parsedModel().deployment` already returns nodes with their tags, instances
+carrying the id of the logical element each one instances, and relationships carrying metadata, so
+the read costs no second parse, no new file format and no change to the frozen CLI surface.
+
+**Required changes**, in the order the dependency graph forces:
+
+1. Walk the deployment model in every `#obl-` grade. Fail-open becomes fail-closed; no new code.
+2. A fourth `Covers:` entry form, `node:<id>`, with the same prefix accepted on either side of the
+   edge form. No new code.
+3. The parse adapter in `src/core/c4/parsed/`, and the deployment records added to
+   `test/likec4-model-parity.test.ts` — a two-stage substitution nothing measures is an assumption.
+   `src/core/c4/` holds exactly five files, so this is a sub-package and not a sixth module.
+4. **No new finding code, and this is a correction the implementation earned.** The item planned
+   two. The first, for a tagged node or edge no living arch requirement covers, turned out to be
+   `obligation.uncovered` asked of a second model: once step 1 walks the topology, the existing code
+   answers it, and a caller acts identically either way — write a `Covers:` line. A second code for
+   one question is exactly what the add-a-code checklist refuses. The second, for a container no
+   deployment instances, is declined outright: it asserts that everything modelled ought to be
+   deployed somewhere, which is a COMPLETENESS claim, and completeness is the one thing
+   `src/core/brief/unchecked.ts` says loam never checks. It is the same category error as the
+   at-least-two-datacenters rule below, one axis over.
+5. `features/<FEAT>/deployment/<name>.likec4`, create-only and copied whole — `core/usecases/delta/`
+   one axis over. It works because `extend` was measured to resolve across documents of one project,
+   so no text splice is needed; `delta-blocks.ts` goes on refusing a `deployment { }` block inside
+   `delta.likec4` and its message names the new slot. The collision is on the FILE, never on what is
+   inside it: two features may both extend one living region from documents of their own and both
+   archive, which is the shape the fleet-wide change actually takes.
+
+   **Graded against the merge preview**, which shipped one commit behind the slot and is the
+   second code, `deployment.doc-invalid` (error, never overridable). This axis needs the post-merge
+   corpus more literally than the use-case one: a feature that stands a NEW service up in a cluster
+   declares it in `delta.likec4` and instances it in the topology, so the element the document names
+   exists only after the merge. The staging that makes that readable moved OUT of
+   `core/usecases/delta/overlay.ts` into `core/c4/project/staged.ts` rather than being copied — the
+   two axes would have disagreed first about the merge preview, which is the one thing both
+   refusals rest on. The extraction dropped `core/usecases/` → `core/kernel/`, which is a one-line
+   edge and was edited into the model directly.
+6. The surfaces: the topology in the context pack (`context --json`'s `living.deployment`), the code
+   table `test/codes-drift.test.ts` requires, and one more statement in
+   `src/core/brief/unchecked.ts`. `loam explain` needed nothing — it parses the /loam-check fix
+   tables at runtime, so the rows added there ARE the entries. The scorecard row the item listed was
+   dropped: the fleet scorecard aggregates at the bound `service`, and a topology row there would
+   count deployment nodes against a denominator no service owns.
+
+**Exit criteria.** Every step above green under the full gate; `covers.unknown` demonstrated firing
+on a covered node that a topology change renamed, which is the acceptance criterion the trigger
+names; the parity suite extended and shown to fail against an un-extended adapter; and
+`test/self-model.test.ts` re-pinned once FEAT-1 archives.
+
+**Out of scope, and each refusal is load-bearing.** No reading of Terraform, Helm or cluster state —
+that is the extractor the non-goals forbid. No check that a service is deployed in at least two
+datacenters: it would need `criticality` promoted from prose to a read field, and it would turn
+`architecture/obligations.yaml` into the policy engine that file says in its own words it is not. A
+multi-datacenter rule is an authored requirement whose `Covers:` line names the nodes; loam grades
+the join and never the architecture. And no `environment` concept above LikeC4, because
+`deploymentNode` is that mechanism and the fleet names its own kinds.
+
+**The evidence, and its one gap stated plainly.** Operator: a team standing up a standby cluster in
+a second datacenter. Repeated task: keeping RTO/RPO requirements attached to a topology that keeps
+changing. Failure mode: a requirement about replication staying green after the node it described
+was renamed or removed. Frequency: every topology change, which is the cadence a migration runs at.
+Current workaround: a `Covers:` line that resolves to nothing, or no written requirement at all.
+Acceptance criterion: a topology change that orphans a covered requirement is convicted without a
+human noticing it first. **That is one operator, not two.** The maintainer judged the trigger
+sufficient on the same basis recorded for landscape scaling and the authored business axis, and the
+[Later](#later--promote-only-from-evidence) exit criteria are amended below to say so rather than
+leaving the two paragraphs to contradict each other. Steps 1 and 2 do not rest on that judgement at
+all: the first is a fail-open defect and the second is a grammar entry, and neither is a new axis.
+
+
 - **A feature can bring a use case.** `features/<FEAT>/usecases/<name>.likec4` — a views-only
   document `loam archive` copies into `architecture/usecases/` and `loam unarchive` takes back,
   create-only, refused by `usecase.flow-exists` when the living tree already holds that file. All
@@ -247,6 +369,18 @@ item gets promoted — it went from here to `## Now` and from there to
 - **UI generation:** begin with a disposable projection over the stable JSON contract only after CLI
   consumers demonstrate a repeated navigation problem. It must not introduce a second mutable state,
   hidden workflow state, or a required service.
+- **A graded subsystem/model correspondence:** a fleet that draws its landscape as grouped C4 states
+  its grouping twice — once as directories under `services/`, once as the nesting of the elements —
+  and `loam subsystem move` changes the first while the second stays put. Since 2026-09-02 the
+  generated views file DISCLOSES that (the `// model: no boundary — …` line; see
+  [SCHEMA.md](SCHEMA.md)), and nothing grades it, because grading placement against the map is the
+  policy the tree is defined not to carry. The shape a graded version would take is known and
+  measured: an author's opt-in `metadata { subsystem '<name>' }` on the grouping element, read
+  through the existing metadata reader, the NAME rather than the path (names are unique in one flat
+  namespace and survive a move, which a path binding would not), with the check structurally silent
+  for every fleet that never writes one. Promote only on evidence from a second fleet, after living
+  with the disclosure — the first report classified itself `inconclusive`, and one fleet is not
+  enough to qualify an invariant that says placement is never part of any identity.
 - **Landscape scaling:** retain one landscape while conflicts are exceptional. If same-service
   conflicts become routine — the current trigger in [SCHEMA.md](SCHEMA.md) is weekly rather than
   monthly — evaluate service-owned model files plus a thin global cross-service map. Migration must
@@ -264,8 +398,11 @@ item gets promoted — it went from here to `## Now` and from there to
 
 Exit criteria for promoting a Later item:
 
-- Evidence comes from at least two independent operators or fleets, except landscape scaling and the
-  authored business axis, whose recorded triggers are sufficient.
+- Evidence comes from at least two independent operators or fleets, except landscape scaling, the
+  authored business axis and — added 2026-09-02 — the deployment axis in [Now](#now), whose recorded
+  triggers are sufficient. Three exceptions is where this criterion starts describing the rule
+  rather than the exception: the next single-operator promotion has to say why the criterion should
+  survive, or retire it.
 - An ADR compares the existing workflow, external tooling, and the smallest loam-owned change.
 - A prototype is measured against a predeclared acceptance criterion and preserves every non-goal
   below.
@@ -276,7 +413,7 @@ Exit criteria for promoting a Later item:
 
 Placed in a section of its own, and the placement is the argument. This is not a `## Now` item, and
 nothing here may be mistaken for one. It is not a "Later" candidate either: promotion
-from that section requires evidence from at least two independent operators or fleets (bar the two
+from that section requires evidence from at least two independent operators or fleets (bar the three
 whose recorded triggers were judged sufficient when they were written), and loam's own repository is
 one operator by construction, so a Later entry could only ever be a permanent exception to the rule
 it sits under. Nor is its value speculative — the trigger below is a defect this repository has

package/SCHEMA.md

@@ -164,9 +164,41 @@ check uses; a member nothing models is omitted, which `landscape.service-unmodel
 reports). The output is deterministic and line-oriented — subsystems sorted by path, members by id,
 one `include` per line, no timestamps, no absolute paths — so it is byte-reproducible on any machine
 and two concurrent moves into different groups merge in git without intervention.
+
+Each view carries the **label a human reads**: `title`, and `description` when the marker authors
+one. The title is the subsystem's **path** — every marked ancestor's label and its own, joined with
+` / `, so `services/platform/order-flow` reads `Platform / Order flow` — and each label is the
+marker's `title`, falling back to the directory name (an unlabelled view is shown by its id, which
+is hex-escaped for injectivity and reads as `subsystem_platform__order_2dflow`). LikeC4
+reads that path as folders: the view list mirrors the directory tree, showing one folder per
+ancestor and the leaf's own label as the title. A `/` **inside** a label becomes `∕` (U+2215), so an
+authored slash can neither hide half of what somebody wrote nor invent a folder level the tree does
+not have. Both strings are somebody's prose written into syntax, so both are normalized to one line
+and escaped. Titles are not unique — only ids are — and renaming a parent's title rewrites every
+view beneath it.
+
+The **boundary** each view draws is a fact about the landscape, never a setting:
+
+1. an element that holds *exactly* the subsystem's members and nothing else is included beside the
+   leaves, so the renderer nests them in the box the author drew, under the author's title;
+2. a landscape that nests nothing puts the services in a `group '<title>'` of loam's own, mirroring
+   the directory subtree, so a parent subsystem shows its children as boxes rather than one pile;
+3. members that ARE nested with no element owning exactly them get no box and one comment line —
+   `// model: no boundary — <id> also holds services outside this subsystem.` — because a synthetic
+   box would look identical whether or not the tree and the map agree. That comment is the whole of
+   what loam says about the two disagreeing: nothing grades it, nothing fails on it, and it lands in
+   the diff of the commit that caused it. **The tree and any `group` nesting in the landscape stay
+   independent**; `loam subsystem move` never rewrites the map, and no finding compares them.
+
+Because the boundary depends on which *other* services sit under an element, an unrelated adoption
+or archive can flip a view from boxed to flat — a new reason to see `subsystem.views-stale`, and why
+`loam archive` withholds its "complete + current" line and names `loam subsystem sync` when it left
+the file behind.
+
 `loam subsystem sync` is the one regenerator (it also *removes* the file when the tree has no
 subsystems), every `loam subsystem` write verb regenerates it inside the same transaction, and
-`validate --all` grades staleness by **byte comparison** — exactly one error,
+`validate --all` grades staleness by **content comparison** (line endings normalized; a CRLF
+checkout changes no fact) — exactly one error,
 `subsystem.views-stale`, on exactly that file; nothing in loam ever parses it: a views-only document
 does not parse standalone (its `include` lines reference elements the landscape defines), and it
 holds **static** views, whose contents loam never reads in any document. Only the LikeC4 renderer,

package/dist/commands/archive/plan/gate.js

@@ -142,19 +142,23 @@ export async function gate(config, featureId, opts, say) {
     // the rest. The register is issue.ts's `approveOverrides` — the same data
     // the `overridable` key in the envelope is resolved from — never a code
     // string spelled here, because two spellings of "what the flag moves" would
-    // drift. Today the register holds one code: a `metadata { service }` binding
-    // the id grammar refuses, anywhere in a tagged element's spliced block. The
-    // landscape merge would splice that name into the living map verbatim, and
-    // the new-service scan would probe `services/<binding>/` with it — a '../'
-    // collapses the probe out of services/ altogether — so the refusal is a
-    // mechanical fact about the path the name becomes, not a judgment about the
-    // feature. Same doctrine as the illegal-specs-name refusal above; the dry
-    // run is gated the same way, and the --json envelope stays not-coherent
-    // with every issue attached, exactly like the overridable branch below, so
-    // a consumer branches on the code and not on which refusal path fired.
+    // drift. What the register HOLDS has grown: it began as one code (a
+    // `metadata { service }` binding the id grammar refuses, where the merge
+    // would splice the name into the living map verbatim and probe
+    // `services/<binding>/` with it) and now holds the create-only collisions of
+    // every whole-file axis besides. They share the doctrine and nothing else —
+    // each is a mechanical fact about what the merge would write, never a
+    // judgment about the feature — which is why the message below counts them
+    // and lets each issue say its own sentence.
+    //
+    // IT USED TO NAME BINDINGS, and had been wrong for every other code in the
+    // register since the use-case slot landed: a feature whose flow collided
+    // with a living one was refused with "1 element binding(s) name an illegal
+    // service id", about a feature that binds nothing. A refusal headline that
+    // describes the wrong breach sends its reader to the wrong file first.
     const nonOverridable = issues.filter((i) => !approveOverrides(i));
     if (nonOverridable.length > 0) {
-        const msg = `archive ${id} — BLOCKED: ${nonOverridable.length} element binding(s) name an illegal service id; --approve does not override this`;
+        const msg = `archive ${id} — BLOCKED: ${nonOverridable.length} issue(s) --approve does not override; each names what the merge would write`;
         if (json) {
             refuseJson("not-coherent", msg, issues, `features/${dirName}`);
             return null;
@@ -166,7 +170,9 @@ export async function gate(config, featureId, opts, say) {
         // line says which of the marks the flag cannot move.
         for (const i of issues)
             console.error(`  ${SEVERITY_MARK[i.severity]} ${i.message}`);
-        console.error(`\nOf these, --approve does not override the ${nonOverridable.length} illegal binding(s) — the merge would write a name loam can never resolve into services/, mechanically. Fix the binding(s); the other issues gate as usual.`);
+        console.error(`\nOf these, --approve does not override ${nonOverridable.length}: ${[...new Set(nonOverridable.map((i) => i.code))].sort().join(", ")}. ` +
+            "Each is a mechanical fact about what the merge would write — a name loam cannot resolve, or a file it would replace wholesale — not a judgement the flag can move. " +
+            "Fix those; the other issues gate as usual.");
         sayExplain("not-coherent");
         process.exitCode = 1;
         return null;