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

package/CHANGELOG.md

@@ -10,6 +10,3454 @@ 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.13] - 2026-10-22
+
+Everything on `main` since `0.2.0-alpha.12`. Still a prerelease on the `alpha` line. When this
+version was cut, `0.2.0-alpha.10`, `0.2.0-alpha.11` and `0.2.0-alpha.12` were tagged but none of
+their publishes had run (`alpha` and `latest` both named `0.2.0-alpha.9`), so a repository
+upgrading from alpha.9 takes alpha.10's, alpha.11's and alpha.12's sections below as well as this
+one; `npm view @ybotok/loam dist-tags` is the record of what installs.
+
+Almost all of it changes what an agent reads before it writes, not what a check grades. A fifth
+reference page, `loam instructions loam-drawing`, teaches seven relationship kinds with one arrow
+direction each, a direction only from evidence (`connects` otherwise), a `legend` view drawn from
+real edges, and overview views that answer one question at one altitude, measured at the LikeC4
+1.59.2 pin. `loam instructions loam-authoring` gains "Writing for a person": an intent.md that says
+how to read the feature, a plain-language `## Purpose` for each spec delta, and requirement bodies a
+person can read. The workflow pages point at both, and `loam explain` defines `kind`, `legend`,
+`overview` and `purpose`. The map `loam init --create` scaffolds and the one `loam seed` writes now
+declare the seven kinds in their `specification` block. A map an earlier loam scaffolded and nobody
+touched still reads as the stub, but it declares no kind: add the block from the drawing page before
+a feature draws a kinded edge, because `loam archive` refuses `merge-failed` on a kind the living
+map lacks and `validate --feature` and `loam status` do not predict that refusal yet.
+
+No document changes its exit code. The only runs that do are lookups of the new names:
+`loam instructions loam-drawing`, and `loam explain` on `kind`, `legend`, `overview`, `purpose` and
+their aliases (`publishes`, `delivers`, `arrow` and `direction` among them), exit 0 where they
+refused `unknown-target`.
+
+No stable code was added, renamed or retired — 360 in all, as at alpha.12, counted with
+`loam explain --codes --json` — and no flag, `--json` key or frontmatter field was added. The new
+page is a fifth entry of `loam instructions --json`'s `references[]` and the MCP resource
+`loam://instructions/loam-drawing`, and the four terms are new entries of `loam explain --json`'s
+`terms[]`.
+
+### Added — `loam instructions loam-drawing`, and agent pages that teach a picture and a feature a person can read
+
+No code, flag or exit code was added or changed. The new page holds the convention.
+SCHEMA.md, "Which way an edge points", states the one part of it loam itself depends on.
+
+- **A fifth reference page, `loam instructions loam-drawing`**, also served over MCP as
+  `loam://instructions/loam-drawing` and listed as a fifth entry of `loam instructions --json`'s
+  `references[]`. It teaches how to draw the C4 model so a person can read it. It names seven
+  relationship kinds, each with one direction: `publishes` (producer to topic), `delivers` (topic
+  to consumer), `reads`, `writes` and `readsWrites` (always written service `->` store, with the
+  kind's style placing the arrowhead), `calls`, and `connects` for a connection whose direction
+  no evidence establishes. Kinds are declared once in the map's `specification` and again in a
+  delta that draws one, never carry a tag, and never use the dotted `a .kind b` form. A
+  `legend` view is drawn from real edges. The page also covers overview views, measured at the
+  LikeC4 1.59.2 pin: one question at one altitude; a single positive `where kind is …` filter,
+  because relationships of different kinds merged into one line render default gray; the
+  `include <parent>.* -> * where …` form, which renders an empty view at subsystem altitude;
+  `rank` rows; `tail odot` on a direction-less edge; numbered titles; and no authored
+  `view … of` a subsystem or service element. `AGENTS.md`'s "Reference pages" section lists the
+  page, and loam-adopt, loam-feature, loam-implement, loam-check and loam-ship point at it
+  wherever an edge is drawn or read.
+- **Adoption resolves directions, and a feature draws messages through the broker.** Step 3 of
+  loam-adopt gives every edge a kind, and a direction only from evidence: the code, a
+  `*_PRODUCER_*` or `*_CONSUMER_*` configuration name, or the service's own `asyncapi.yaml`.
+  Configuration that only names an address is drawn `connects`, and the adoption turns the
+  service's `connects` edges into real kinds. Its hand-back now says eight things; the new one
+  is every edge still drawn `connects`. loam-feature's delta step draws producer
+  `-[publishes]->` topic `-[delivers]->` consumer, and draws a producer outside the fleet as an
+  `#external` element. loam-implement redraws a `connects` edge once the code shows its kind.
+- **`loam instructions loam-authoring` gains "Writing for a person".** It covers intent.md's
+  `## How to read this feature`, a business-requirement coverage table, and `## Open questions`
+  as a table (ID, question, blocks, owner, current default). Each spec delta gets a
+  plain-language `## Purpose`, which is copied into a document the archive creates and stays
+  with the archived delta otherwise. A long requirement body becomes a one-line lead plus one
+  bullet per SHALL sentence, and abbreviations are expanded on first use. Wording such as
+  "this delta" or "this feature" stays out of what the archive copies. It also covers feature
+  glossary terms, feature ADRs, use cases tagged `#cap-`, and `Covers:` edges spelled by
+  service name. loam-feature's step 4 and loam-ship's dry-run step say the same in brief, and
+  loam-feature's analyze step writes open questions as table rows.
+- **`loam explain` knows the new words.** A fifth listing heading, "the picture — drawing the
+  map and writing for a person", holds `kind` (which also answers `publishes`, `delivers`,
+  `reads`, `writes`, `readsWrites`, `calls`, `connects`, `arrow` and `direction`), `legend`,
+  `overview` and `purpose`. `loam explain --json`'s `terms[]` gains the four.
+- **loam-report** rebuilds a reproduction on neutral stand-ins when the fleet's own names are
+  confidential, and its `Sanitization` section says when `Actual` quotes the fleet.
+
+### Changed — a new fleet map declares the seven relationship kinds
+
+- The `architecture/landscape.likec4` that `loam init --create` scaffolds, and the map
+  `loam seed` writes, now declare `publishes`, `delivers`, `reads`, `writes`, `readsWrites`,
+  `calls` and `connects` in their `specification` block, with the styles the drawing page
+  teaches. The stub's comment shows each kind in use. Seed's edges stay plain: `fleet.yaml`
+  says who calls whom and nothing about what an edge carries.
+- No `legend` view is scaffolded. A view names only elements the model declares, and a new map
+  declares none.
+- A map an earlier loam scaffolded and nobody touched still reads as the untouched stub:
+  `loam status` keeps its `next.author-landscape` step and `loam seed` still replaces it. Such a
+  map declares no kind, so add the block from `loam instructions loam-drawing` before a feature
+  draws a kinded edge. `loam archive` copies an edge and never a declaration, and refuses with
+  `merge-failed` on a kind the living map lacks. `loam validate --feature` and `loam status` do
+  not predict that refusal yet.
+
+## [0.2.0-alpha.12] - 2026-10-22
+
+Everything on `main` since `0.2.0-alpha.11`. Still a prerelease on the `alpha` line. When this
+version was cut, `0.2.0-alpha.10` and `0.2.0-alpha.11` were tagged but neither publish had run
+(`alpha` and `latest` both named `0.2.0-alpha.9`), so a repository upgrading from alpha.9 takes
+alpha.10's and alpha.11's sections below as well as this one; `npm view @ybotok/loam dist-tags` is
+the record of what installs.
+
+Both entries close a gap between what a feature's checks say and what the archive then does. A
+feature that REMOVES a requirement a living flow's `#req-` tag claims, or MODIFIES one and adds an
+id that flattens to the same tag, is refused at feature scope with
+`usecase.requirement-unresolved` — the error `validate --all` used to report only after the
+archive — and that walk reads a service-local tag against both of the service's documents, as the
+fleet does. `loam rebase` writes a contract's `x-loam-based-on` pin and `x-loam-baselines` record
+without re-printing the rest of the feature's `openapi.yaml` or `asyncapi.yaml`.
+
+One entry changes an exit code. The refusal is new: `loam validate --feature`, `validate --all` for
+an active feature and `loam archive` (`not-coherent`, which `--approve` overrides) exit 1 for a
+feature whose merge breaks a living flow's `#req-` tag where they exited 0, and `loam status` no
+longer calls that feature ready. Under `--strict`, a `usecase.requirement-modified` warning that
+reading both of a service's documents takes away can let a run pass that failed. `loam rebase`
+changes no exit code.
+
+No stable code was added, renamed or retired — 360 in all, as at alpha.11, counted with
+`loam explain --codes --json` — and no flag, `--json` key or frontmatter field was added.
+
+### Fixed — a feature that removes a promise a living flow claims is refused before the archive
+
+No code, flag or payload key was added. SCHEMA.md "A promise a living flow keeps, removed" states
+the rule.
+
+- **`usecase.requirement-unresolved` is raised at feature scope for a living flow.** A feature that
+  REMOVES a requirement a living flow's `#req-` tag claims passed `validate --feature`, `loam status`
+  and the archive gate, archived at exit 0, and the next `validate --all` reported
+  `usecase.requirement-unresolved` against the flow. The walk that raises
+  `usecase.requirement-modified` now raises that error too, at both of its altitudes: an
+  `architecture/` flow scoped by its `#cap-` tag to a capability requirement the feature's capability
+  delta removes, and a flow beside a service's model naming one of that service's requirements the
+  feature's `specs/` delta removes. The message names the living flow file and the requirement, and
+  the subject is the view, as `validate --all` names it. `--approve` overrides it. The tag is graded
+  against what the merge leaves: a removal the same delta re-spells under an id that flattens to the
+  same tag raises nothing, and a tag that does not resolve today is left to `validate --all`, which
+  already reports it. **Exit code:** `loam validate --feature`, `validate --all` (per active feature)
+  and `loam archive` (`not-coherent`) now exit 1 for such a feature where they exited 0, and
+  `loam status` no longer calls it ready.
+- **A MODIFIED that leaves a living flow's tag ambiguous is the same error, not the warning.** A
+  feature that MODIFIES a requirement a living flow claims and ADDS an id that flattens to the same
+  tag (`PAY-AUTH` beside `PAY.AUTH`) got only `usecase.requirement-modified`, whose message said the
+  tag would still resolve; after the archive `validate --all` reported `usecase.requirement-unresolved`.
+  It now gets that error, naming the colliding ids, with the same exit codes as above.
+- **A service-local `#req-` tag is read against both of the service's documents in this walk, as the
+  fleet reads it.** When the feature carried a delta for only one of spec.md and arch.spec.md, the
+  other was not read, so an id it declared did not count; and a requirement under a living document's
+  `## REMOVED Requirements` heading counted, though the fleet skips it. Both now match
+  `validate --all`. For `usecase.requirement-modified` this can only remove a warning, from a tag the
+  two documents already make ambiguous.
+
+### Fixed — `loam rebase` pins a feature's contract without re-printing it
+
+No code, flag, exit code or `--json` key was added or removed.
+
+- **A rebased `openapi.yaml` or `asyncapi.yaml` changes only where loam pins it.** Writing an
+  `x-loam-based-on` pin, or writing or removing the root `x-loam-baselines` record, re-printed the
+  feature's whole contract: every long scalar re-folded at 80 columns, every flow sequence
+  re-padded (`[a, b]` became `[ a, b ]`) and CRLF turned into LF. Now only the pin lines and the
+  record change and the rest of the file stays byte-for-byte as written, with the same fallback to
+  the whole-file write that the archive's merges use for a shape they cannot splice safely. A
+  contract an earlier rebase already re-printed stays as it is: rebasing it again does not bring
+  back the author's layout.
+
+## [0.2.0-alpha.11] - 2026-10-22
+
+Everything on `main` since `0.2.0-alpha.10`. Still a prerelease on the `alpha` line. When this
+version was cut, `0.2.0-alpha.10` was tagged but its publish had not run (`alpha` and `latest` both
+named `0.2.0-alpha.9`), so a repository upgrading from alpha.9 takes alpha.10's section below as
+well as this one; `npm view @ybotok/loam dist-tags` is the record of what installs.
+
+Most of it makes a grade or an archive say what it used to decide in silence. An event key on an
+edge drawn the wrong way round is named instead of binding nothing, the consumer census counts a
+service at either end of an edge into a store or a topic, and a `Covers:` line may name a kinded
+edge. `loam archive` merges an edge whose relationship kind carries a tag, reads an extending
+model's dotted edges and kind-first declarations, keeps a comment with the statement under it, and
+gives a service it creates its own `services/<svc>/model.likec4`. A feature's new services are the
+ones the archived fleet will call services, and `loam status` owes an `openapi.yaml` only where
+something calls the service. The archive names every scenario and join-line entry a MODIFIED or
+REMOVED requirement takes out of the living docs, marks a first spec.md it writes into a
+never-adopted service `adoption: partial`, and writes only the entries a contract merge changes. A
+use-case step's title can say which of several relationships its hop means.
+
+Several entries change an exit code, listed in each. Refusals that are gone: `loam archive` and
+`archive --dry-run` on an edge whose relationship kind carries a tag or on a child of a kind-first
+container in an extending model, and the `usecase.flow-invalid` / `deployment.doc-invalid` that
+`validate --feature`, `validate --all` and `loam status` reported for the same shapes. Refusals that
+are new: a feature's use-case hop or deployment document naming a container the delta draws inside
+a service the feature introduces is `usecase.flow-invalid` / `deployment.doc-invalid` from
+`validate --feature`, `validate --all` for an active feature and `loam archive` (`not-coherent`,
+which `--approve` does not override); on the tagged-kind shape `validate --feature` can now report
+`spine.message-unproduced`; and `loam gate --service <id>` exits 1 for a service whose first
+spec.md an archive wrote as `adoption: partial` (`gate.service-undocumented`). Under `--strict` the
+new warnings can fail a run that passed — `spine.message-unbound`, `usecase.requirement-modified`,
+`openapi.info-not-merged`, `asyncapi.info-not-merged`, `gate.partner-undocumented`, and
+`landscape.datastore-shared` / `landscape.platform-candidate` now that the census counts both ends
+— and the warnings that are gone (`service.no-requirement-delta` on an `#external` producer or a
+living element's stub, `c4.uncovered` on a grouping, a `usecase.step-contested` hop its title
+resolves) can let one pass that failed.
+
+Four stable codes were added, all warnings that never gate — `spine.message-unbound`,
+`usecase.requirement-modified`, `openapi.info-not-merged` and `asyncapi.info-not-merged` — 360 in
+all, 356 at alpha.10; none was renamed or retired, and no flag was added. New `--json` keys, all
+additive: `dropped` on `loam archive` and on `loam delta`, and `partial: true` on the spec.md entry
+of `loam adopt`'s `targets[]`. `loam archive --json`'s `plan` gains a `create` row for a service
+model it writes, and `loam status` can read a new service's `openapi` as `done` with
+`required: false`. One frontmatter field is new, written by loam: `adoption: partial`, which stays
+until the service's baseline is written and the line is deleted.
+
+### Fixed — which way an edge points no longer decides a grade in silence
+
+One finding code was added: `spine.message-unbound` (warn). It is a new member of the frozen
+`IssueCode` union. No flag or payload key changed, and no exit code changed except under `--strict`,
+where every new warning below fails the run. SCHEMA.md has a new section, *Which way an edge
+points*, that lists every reader of a relationship's direction and the drawing each one expects.
+Until now the event rule was written only in the examples README.
+
+- **An event key bound to a topic is reported.** `metadata { publishes }` binds the edge's SOURCE
+  and `metadata { consumes }` binds its TARGET. A consume edge drawn from the consumer to the topic,
+  or a publish edge drawn from the topic to the producer, bound nothing: the document validated, and
+  the event spine graded one link fewer without a word. `loam validate` (`--service`, and `--all`
+  per service) now raises `spine.message-unbound` on the service at the other end when the bound end
+  is infrastructure: a `topic`, `queue`, `database`, `cache` or `bucket`, by its own kind or an
+  ancestor's. `validate --feature`, `loam status <FEAT>` and the archive gate raise it for a delta's
+  tagged edges. The message spells the edge turned round. For an edge that carries both keys it says
+  to move the key at fault onto an edge of its own, since turning the arrow round would only move
+  the warning. The warning does not gate. While it stands, the service's `event.covered` line does
+  not appear. An `#external` system at the bound end does not raise it: `crm -> billingService`
+  carrying `publishes` is an outside producer, and a `consumes` on an outside system is an outside
+  consumer, both drawn correctly. Neither does an edge with no fleet service at either end.
+- **The consumer census counts a service at either end of an edge into infrastructure.** For an
+  infrastructure element that stands for no service, `store -> service` now counts that service as
+  a consumer, as `service -> store` already did, and so does an extending model's inbound call from
+  such an element. Two drawings now warn that did not. A store a second service reads, drawn
+  `store -> service`, raises `landscape.datastore-shared`. An `#external` broker not tagged
+  `#platform` raises `landscape.platform-candidate` once three services reach its topics, counting
+  services that only consume, drawn `topic -> service`. Before, only publishers were counted. **This
+  can add a warning to a fleet that had none, and fail `--strict` with it.** While either warning
+  stands, `validate --all` does not print `landscape.matched`. For any other element the arrow is
+  still read, so a system calling into the fleet is not consumed by the services it calls.
+- **A `Covers:` edge entry may carry the relationship's kind**, in either of LikeC4's spellings.
+  `a -[kind]-> b` used to split at the `->` after the `]`, and `a .kind b` was read as one element
+  id, so both were always `covers.unknown` while `a -> b` matched the same kinded edge. Both now
+  resolve exactly as `a -> b` does, at service and feature scope, and satisfy `c4.uncovered` the
+  same way. `node:a -[kind]-> node:b` reads as a deployment edge. The kind is read past, not
+  compared, because loam identifies an edge by its two endpoints.
+
+### Fixed — `loam archive` splices what LikeC4 reads, where a reader expects it, and gives a service it creates its model
+
+No code, flag or payload key was added. SCHEMA.md "How archive writes, and how unarchive undoes it"
+states the rules.
+
+- **An edge whose relationship kind carries a tag archives.** With `relationship publishes { #async }`
+  in the specification, every `-[publishes]->` (or `.publishes`) edge the delta added was refused as
+  `merge-failed` ("cannot locate the '…' relationship in delta.likec4") by an archive
+  `validate --feature` and `loam status` had called ready, and a feature with flows got
+  `usecase.flow-invalid` from `validate --feature` instead. The splice now matches a statement with
+  its kind's tags. **Exit code:** `loam archive` and `archive --dry-run` exit 0 where they exited 1
+  on that shape; `validate --feature`, `validate --all` (per active feature) and `loam status` no
+  longer carry the `usecase.flow-invalid` — or, for a feature with `deployment/`, the
+  `deployment.doc-invalid` — and exit 0 where they exited 1. With the merge preview readable again,
+  `validate --feature` also checks a consumed message against the map the archive leaves, so on that
+  shape it can now report `spine.message-unproduced` where it said nothing.
+- **An extending model is read with the kinds it borrows from the map.** In a service's extending
+  `model.likec4`, a dotted edge (`a .delivers b`) and a kind-first declaration (`container outbox …`)
+  were invisible to the splice: an edge the archive routed into the model landed above the dotted
+  edge and its comment, a delta restating a dotted edge wrote a second copy at exit 0, and a child of
+  a kind-first container was refused (`merge-failed`, "nests under … which is neither in the living
+  landscape nor added by this delta"). **Exit code:** that last shape exits 0 where it exited 1 —
+  `loam archive`, and `validate --feature` and `loam status` for a feature with flows or
+  `deployment/`, which reported the same refusal as `usecase.flow-invalid` / `deployment.doc-invalid`.
+- **An addition with no anchor lands above the comment written over the statement after it, and
+  where it lands no longer depends on unrelated edges.** On a hand-written map, an edge from a
+  service the same archive adds was spliced between a section comment and the edge it explains, and
+  turning one unrelated edge round moved it to another section. The relationship walk now sorts only
+  within the region's ascending tail, and a comment directly above a statement or the model's
+  closing brace stays with what follows it — in the landscape and in a service model alike. The bytes
+  an archive writes change only for those shapes; placement stays order-independent.
+- **A service the archive creates gets `services/<svc>/model.likec4`.** For a service the feature
+  carries `specs/<svc>/` for, the fleet does not enumerate and the merged map draws (the living map,
+  or an element the delta adds, bound to it or titled with its name), the archive writes an empty extending
+  model (a header comment and `model { }`) and routes whatever the delta draws inside the service
+  into it, where those containers used to land on the map. `loam archive --json`'s `plan` gains a
+  `create` row for that path, the run prints `architecture: created services/<svc>/model.likec4 …`,
+  and `warnings[]` no longer carries `service.no-model` for that service — so the closing "complete
+  + current" line is no longer withheld for it, and `validate --all` reports no `service.no-model`
+  after it. `service.no-model` is still filed (error, `gates: false`) for a service the map gains with
+  no `specs/<svc>/`, which `validate --all` then reports as `landscape.binding-unknown`, and for a
+  `specs/<svc>/` the merged map never draws (an unknown service only `--approve` merges), when the
+  merge creates its directory anyway. The archive
+  never picks a subsystem — the service lands unfiled at `services/<svc>/` unless its directory
+  already exists — and when the tree has a subsystem it prints
+  `loam subsystem move <svc> --into <subsystem>`. `unarchive` deletes the created model. The
+  shipped example's FEAT-101 now archives with no warning and a fleet that is clean after
+  `loam subsystem sync`.
+- **The feature gate previews that routing.** A `features/<FEAT>/usecases/` hop into a container
+  the delta draws inside a service the feature introduces resolved against the preview's map, passed,
+  and was copied into `architecture/usecases/`, naming a container that now lives in the service's
+  model. **Exit code:** `loam validate --feature`, `validate --all` (per active feature) and
+  `loam archive` (`not-coherent`; `--approve` does not override it) now refuse that shape with
+  `usecase.flow-invalid` where they passed, and `loam status` no longer calls that feature ready. A
+  `features/<FEAT>/deployment/` document naming such a container is refused the same way, with
+  `deployment.doc-invalid`.
+
+### Fixed — what a feature introduces is graded the way the archived fleet grades it
+
+No code, flag or `--json` key was added. A feature's delta was read with a narrower idea of "a
+service" than the fleet census `validate --all` applies once the archive lands, and `loam status`
+owed a contract to every service a feature introduces whether or not anything could ever call it.
+
+- **`service.no-requirement-delta` (warn) fires only for a new service of ours**: a tagged
+  `softwareSystem` at service level that is not `#external`, not a grouping (an element standing
+  for no service that contains one), has no `services/<id>/` and is not already drawn by the living
+  map. A delta's `#external` producer, and the stub of a living element — read with the living
+  element's tags, so a re-declared `#external` system stays external — no longer raise it.
+- **The verification checklist's `service.exists` claims follow the same reading**, so
+  `loam verify` and `loam tasks` lose the claim and unit for an `#external` element, a grouping, and the
+  stub of a living `#external` system — and GAIN one for a new service drawn inside a group the
+  delta declares (the shape the shipped `FEAT-101` uses for `payment-split-service`), which a
+  dotted id used to hide. Only a grouping is looked through: what a delta draws inside any other
+  element (a container of a system with no directory yet, an endpoint inside an `#external`
+  vendor) is still not a service, and the stub of a service that already has a directory is asked
+  about only when tagged at top level, as before. A record answering the old checklist of such a
+  feature reads stale and is answered again.
+- **`c4.uncovered` (warn) no longer asks a grouping for a `Covers:` line**; the service inside it
+  is graded as before.
+- **`loam status` owes an `openapi.yaml` on evidence, in both forms.** A service with no living
+  contract, that no other feature in flight carries one for, owes it when the feature writes an
+  `Operations:` line for it or a tagged delta edge calling an operation on it — the links
+  `spec-api.op-undefined` and `c4-api.op-undefined` grade. A new service nothing calls now reads
+  `openapi` `done` (`required: false`), drops `next.author-openapi`, and leaves the fleet form's
+  `missing[]`, so the feature's stage can move from `missing` to `ready`. An adopted service with
+  no contract that a tagged edge calls with an op now owes one (`required: true`, `missing`,
+  `next.author-openapi`, `<svc>/openapi` in `missing[]`) where status said "none owed" beside the
+  gate's error. When the delta does not parse, the old answer stands. The evidence is the
+  feature's own: another feature's edge into a service this one introduces is that feature's
+  `c4-api.op-undefined` / `c4-api.op-pending`, not a contract this one owes.
+- **`loam archive` does not create a living `openapi.yaml` from a contract that describes nothing**
+  (no path, webhook or component): the plan prints `openapi: <svc> — nothing to merge …, no living
+  openapi.yaml created` instead of `created ()`, and `archive --json`'s plan carries no write for it.
+
+Exit codes: `validate --strict`, which escalates warnings, can exit 0 where one of the warnings
+above was the only one.
+
+### Fixed — the archive says what it replaces, creates and rewrites
+
+Three new stable codes, all warnings that never gate: `usecase.requirement-modified`,
+`openapi.info-not-merged`, `asyncapi.info-not-merged` (360 in all). No flag and no refusal changed;
+the exit codes that move are `loam gate`'s and, under `--strict`, `validate`'s, both below. New
+`--json` keys, all additive: `dropped` on `loam archive` and on `loam delta`, and `partial: true` on
+the spec.md entry of `loam adopt`'s `targets[]`. One new frontmatter
+field, written by loam: `adoption: partial`.
+
+- **A MODIFIED or REMOVED requirement names what it takes away.** A MODIFIED replaces the living
+  requirement whole, so every scenario and join-line entry (`Operations:`, `Covers:`, `Requires:`,
+  `Capability:`, `Realizes:`, `Publishes:`, `Consumes:`) it did not restate vanished at archive
+  under a bare `~1`. The plan now prints one line per replaced or removed requirement naming the
+  dropped scenarios and entries, `loam archive --json` carries them as `dropped`
+  (`[{ path, kind, requirement, id?, scenarios, directives }]`), and `loam delta` carries the same
+  rows as `dropped` and prints them under *Taken out of the living docs by the merge* — on the
+  service's spec.md and arch.spec.md and on every capability document the feature changes. `path`
+  is the living document; `kind` is `MODIFIED`, `REMOVED` or `ADDED` (an ADDED that lands on a living
+  requirement of the same id or name); `id` is absent for a requirement with no `Requirement-ID:`;
+  `directives` is keyed `operations`, `covers`, `requires`, `capabilities`, `realizes`, `publishes`,
+  `consumes`, each present only for a line that loses an entry (a `Realizes:` entry is compared by
+  its target, so a pin is never a drop).
+- **A living flow claiming a requirement the feature MODIFIES is named.** Its `#req-` tag still
+  resolves after the archive and every grade stays green, whatever the new wording says.
+  `usecase.requirement-modified` (warn) now fires wherever the feature is graded — `validate
+  --feature`, `validate --all` per active feature, `loam status <FEAT>`, and the archive's
+  `warnings[]` (it never refuses the archive) — for an `architecture/` flow whose `#cap-`-scoped `#req-` tag claims a capability
+  requirement the feature modifies, and for a flow beside a service's model whose `#req-` tag
+  names one of that service's requirements the feature's `specs/` delta modifies. **Exit code:**
+  unchanged, except under `--strict`, which fails on any warning and so now exits 1 on this shape.
+- **A first spec.md archived into a never-adopted service is marked `adoption: partial`.** When
+  `loam archive` creates `services/<id>/spec.md` for a service that already existed and that the
+  feature does not introduce, the file carries `adoption: partial` and the plan says why.
+  `loam list`, `explore`, the context pack and `validate --all`'s scorecard keep the service at
+  `partial` (`missing` names `loam adopt --service <id>`) instead of `documented`, and `loam status`
+  lists it under `next.adopt`, with a sentence saying the spec.md holds one feature's slice, instead
+  of `next.complete-service` even when it has no model.likec4. **Exit code: `loam gate --service
+  <id>` now exits 1 for such a service** — it sits at `partial`, so `gate.service-undocumented`
+  fires where the same archive used to leave it `documented` and the gate passing; every service
+  joined to it gets `gate.partner-undocumented` (warn: exit unchanged, except under `--strict`).
+  `loam adopt --service <id>` — the command all of those name — flags that spec.md `PARTIAL` and
+  counts it as owed (`targets[]` carries `partial: true`) where it said every required artifact was
+  already there. Delete the line once the service's baseline is written — the brief and the
+  `loam-adopt` protocol now say so — and all of it clears.
+- **The contract merges keep the bytes they did not change.** Archiving into a living
+  `openapi.yaml` or `asyncapi.yaml` re-folded every long scalar at 80 columns, re-padded flow
+  sequences and turned CRLF into LF across the whole file; only the entries the merge adds, replaces
+  or removes are now written, and the rest of the file is byte-identical (falling back to the old
+  whole-file write for a shape it cannot splice safely). A living contract the archive CREATES from
+  the feature's file keeps that file's bytes too, minus the `x-loam-*` keys it strips.
+- **The delta's `info` is not merged, and the plan now says so.** `openapi.info-not-merged` /
+  `asyncapi.info-not-merged` (warn) name every `info` key the feature's contract spells differently
+  from the living one — including for a delta whose only change is its `info` — since the merge
+  keeps the living `info`. Edit the living contract in the same change if it should move.
+
+### Fixed — a use-case hop can say which of several relationships it means
+
+No code, flag or `--json` key was added or removed. Before this, a hop between two elements the map
+joins by edges naming different operations was `usecase.step-contested` (warn) whatever the flow
+said. On a fleet flow (`architecture/usecases/*.likec4`) between two services the map draws as
+single elements, no edit to the flow could clear it: the repair the warning offered — draw the hop
+between the elements that name exactly one candidate — needs containers, and a container an
+extending model declares does not resolve on a fleet flow.
+
+- **A step's title now picks the candidate it opens with.** Where the candidates disagree, a title
+  that STARTS with one candidate's `metadata { op }` — or with the message it `publishes` or
+  `consumes` — and goes on only after punctuation, or not at all, attributes the hop to that
+  relationship: `orders -> payments 'authorizePayment — authorizes the payment'`,
+  `'getOrder(orderId)'`, `'refundPayment'`. The name is matched exactly, case included, as a whole
+  name: a letter, digit, `_`, `.` or `-` after it means it is part of a longer name and picks
+  nothing. A name that is the first word of a sentence (`'read the order'`), a name later in the
+  title, a relationship's own title, a name the pair's candidates do not declare, or one name
+  declared by candidates that still disagree picks nothing, and the hop stays contested over every
+  candidate. A title never backs an unbacked hop and never overrules candidates that agree.
+- **Which findings change.** A hop the title resolves is no longer `usecase.step-contested`.
+  Picked by an operation, it is attributed to that operation. Picked by a message, it is an event
+  hop, which `usecase.step-unlinked` exempts. This holds on the fleet target, on a service's own
+  flows (`loam validate --service`) and on a feature's `usecases/` flows. **Titles written before
+  this release are read the same way**: a step title that already opens with a candidate's
+  operation id and punctuation (`'createOrder: places the order'`) now picks it with no edit, its
+  next `loam validate` stops warning on that hop, and `--strict` can exit 0 where it exited 1.
+- **Contract removals read the same pick.** `loam diff --base` and the contract-removal gate list a
+  picked hop among the flows that break when its operation is removed, and drop the "could not be
+  answered" line they printed for the other candidates' operations. A hop picked by an operation is
+  no longer listed among the flows a removed message breaks, even where another candidate consumes
+  that message; that edge itself still is. Which code fires, and the exit code, do not change: the
+  picked edge was already named as a consumer.
+- **The `usecase.step-contested` message** now leads with how to pick, giving as the example the
+  step's own title behind a candidate's name, and only a title that would clear the warning. Drawing
+  the hop between other elements comes last, for a project that declares those elements. Its
+  `details[]` lines print every name an edge declares — `(op: <id>)`,
+  `(publishes: <message>)`, `(consumes: <message>)`, or `(no op)` when it declares none — where a
+  message edge used to print `(no op)`, and an edge declaring both an operation and a message
+  prints both, `(op: <id>, publishes: <message>)`, where it used to print only `(op: <id>)`.
+
+## [0.2.0-alpha.10] - 2026-10-21
+
+Everything on `main` since `0.2.0-alpha.9`. Still a prerelease on the `alpha` line.
+
+Most of it closes the gap between a feature called clean and the fleet its archive leaves:
+`validate --feature`, `loam status <FEAT>` and the archive gate now raise, before the archive, what
+`validate --all` raises after it. `loam archive` keeps a created document's title, owner and
+`## Purpose`, re-expresses every link it moves — out of the archived feature, and into it from any
+other document — and its undo snapshot no longer breaks a feature's LikeC4 project;
+`loam subsystem move` and `rename` rewrite the links their renames would break. A repository bound
+to a service a feature introduces is pointed at that feature instead of being told to adopt it, by
+`loam status`, `loam doctor`, `loam validate`, `loam show`, `loam context` and `loam steps` alike.
+`loam status`, `loam tasks` and `loam validate` say in words where work stands, `loam explain`
+defines the words they print, and on Windows a rolled-back write takes back the directories it
+created.
+
+Several entries change an exit code, listed in each. Refusals that are new: four feature-scope
+errors (`spine.message-unproduced`, `usecase.step-unbacked`, `usecase.requirement-unresolved`,
+`usecase.capability-unresolved`) fail `validate --feature`, `validate --all` for an active feature
+carrying one, and `loam archive` (`not-coherent`, unless `--approve`); `loam unarchive` refuses
+`snapshot-stale` over a relinked document edited since the archive; `move-uncommitted` also covers
+an uncommitted document outside the moved directories that the move would relink. Refusals that are
+gone: `loam explain` on the seventeen new terms, and `show`, `context`, `steps` and a bare
+`validate` for a service a feature introduces. `loam archive` files `service.no-model` at
+error severity, the severity `validate --all` gives that directory next, and it still does not gate
+(`gates: false`): count what blocks by `gates`, never by `severity`. `loam context` with two
+introducing features refuses `invalid-option` where it said `unknown-service`, and
+`loam tasks <FEAT>` in a repository bound to a service the feature touches lists that service's
+slice. The undo snapshot is now version 4, and an older loam cannot unarchive a feature this version
+archived: upgrade every checkout that may run `loam unarchive`.
+
+No stable code was added or renamed — 356 in all, as at alpha.9 — and no flag.
+`loam archive --json`'s `issues[]` may now carry seven codes `validate` already had
+(`spine.message-unproduced`, `health.uncovered` and five `usecase.*`). New `--json` keys, all
+additive: `staleViews` on `loam unarchive`, `relinked` on `subsystem move`/`rename`, `title`,
+`checklist` and `serviceSteps[]` on `loam status`, `title` on `show` and `list`,
+`currentService.introducedBy` on `loam doctor`, `boundService` on `loam validate`, and `living` /
+`introducedBy[]` on `show`, `context` and `steps` for a service a feature introduces.
+
+### Fixed — the feature gate predicts the fleet its archive leaves
+
+No code or flag was added. A feature `validate --feature` called clean — `loam status` "ready", the
+archive gate agreeing — could archive at exit 0 under "living spec + landscape are now complete +
+current." into a fleet `validate --all` then reported red. The feature scope (`validate --feature`,
+`loam status <FEAT>`, the archive gate and `archive --dry-run`) now raises, before the archive,
+what `validate --all` raises after it, under the same codes — except the two `Covers:` findings
+below, which are `validate`'s alone (`--feature`, and `--all` per active feature); `loam status`
+and the archive do not raise them:
+
+- **A consumer with no producer is refused.** A delta `Consumes:` line or tagged `consumes` edge
+  naming a message nothing would send after the merge — no service's contract as the merge leaves
+  it, no `#external` publisher on the living map or in the delta — is `spine.message-unproduced`
+  (error) at feature scope. When only another in-flight feature's delta sends the message it is
+  `spec-event.message-pending` / `c4-event.message-pending` (warn) instead.
+- **A feature's own flows are graded as the fleet grades them.** A hop of a
+  `features/<FEAT>/usecases/*.likec4` view that no relationship on the post-merge map backs is
+  `usecase.step-unbacked`; a `#req-` tag no `#cap-` tag scopes, or one naming no requirement as the
+  merge leaves the capability document, is `usecase.requirement-unresolved`; an unresolving `#cap-`
+  tag is `usecase.capability-unresolved` — errors. `usecase.step-contested` and
+  `usecase.step-unlinked` arrive as warnings. The messages open with the feature file's path.
+- **A MODIFIED arch requirement that drops a `Covers: sli:` / `alert:` line** the living
+  `arch.spec.md` had is `health.uncovered` (warn) at feature scope, naming the signal.
+- **A `Covers:` entry spelled in the delta's own ids** — a stub the delta declares where the living
+  map nests it, or a child under one — is `covers.unknown` (warn) at feature scope, offering the
+  spelling that resolves in both. An entry spelled the way the merged map will spell an element
+  this feature adds now resolves at feature scope too.
+- **`c4.uncovered`'s hint** offers that same surviving spelling: an edge by its endpoints' service
+  names (`checkout-web -> payment-split-service`), an element by its service or the id the merge
+  gives it — the delta's own id only when the merge preview cannot be computed.
+- **`loam archive` files `service.no-model` at error severity**, because `validate --all` reports an
+  error next — `service.no-model` for the directory the archive creates, `landscape.binding-unknown`
+  for a binding it lands with no directory, which the message now names; it still does not gate (`gates: false` in `--json` `warnings[]`). The text
+  `--dry-run` now prints it, as `--json` and the real run did, before "dry run — nothing was
+  written.", and both runs print in place of the closing line when this archive lands ahead of an
+  in-flight change it waits on (a `spec-api.op-pending`, `c4-api.op-pending`,
+  `spec-event.message-pending` or `c4-event.message-pending` warning).
+- **A `spine.message-unproduced` producer may be an `#external` system the delta draws**, including
+  a living one it re-declares as an untagged stub: the question is asked of the map the merge leaves.
+- **Exit code:** on any of the four errors above, `loam validate --feature`, `loam validate <FEAT>`
+  and `loam validate --all` — for every active feature carrying one, before anything is archived —
+  now exit 1 where they exited 0; `loam archive` and `archive --dry-run` exit 1 (`not-coherent`)
+  without `--approve`, which overrides all four; `loam status` counts them as gating, and
+  `loam show <FEAT> --json` reports `review.readyToArchive: false`. The warnings above
+  (`health.uncovered`, `covers.unknown`, `usecase.step-contested`, `usecase.step-unlinked`, the two
+  `*-pending`) leave the exit code alone except under `--strict`, which fails on any warning and so
+  now exits 1 on these shapes.
+- **`service.no-model` rides at error severity in a `not-coherent` refusal's `error.issues[]`** too,
+  beside the issues that refused — count what blocks by `gates`, never by `severity`.
+
+`loam archive --json`'s `issues[]` may carry the seven codes above (`spine.message-unproduced`,
+`health.uncovered`, the five `usecase.*`), which the `IssueCode` union now admits; each was already
+a stable `validate` code.
+
+### Fixed — `loam archive` keeps what makes the living docs readable, and a link it moves still resolves
+
+No code or flag was added. Two additive `--json` keys (`unarchive`'s `staleViews`, `subsystem
+move`/`rename`'s `relinked`), one new snapshot layout (version 4) and one refusal that is new
+(`move-uncommitted` over a document outside the move). Archive's `plan` gains `update` rows for the
+feature's own documents it relinks and for every document outside the feature whose links into it
+it rewrites, its `revouchOwed` also names a vouched spec that rewrite moves, and `unarchive`'s
+existing `snapshot-stale` refusal now covers all of those documents too. SCHEMA.md "Conventions"
+states the rules.
+
+- **A living document archive CREATES carries what the delta marked as its own.** A new
+  `services/<svc>/spec.md` or `arch.spec.md` used to be a fixed header — `service`,
+  `status: draft`, `# <svc>` — and the requirements; a new `capabilities/<cap>/spec.md` was
+  `# <cap>` and the requirements. The delta's title, its narrative, its frontmatter `owner` and
+  every section around the delta sections were dropped in silence. Now a created document gets the
+  delta's `owner` (service specs), its H1 unless that title is about the change (it names the
+  feature, or calls itself a delta — the scaffold's own title does both, so a scaffolded delta keeps
+  the heading it always had), its `## Purpose` section verbatim, and one sentence linking back to
+  the archived delta ("Created when FEAT-1 was archived; its delta keeps the prose written for that
+  change", with "its delta" the link). The plan prints one note per created document, under that
+  file's line, naming what it carried and where the rest stays. A `## Purpose` in a delta against a
+  document that already exists is not merged, and the plan now says so under that file's line.
+- **A link into the feature lands on the file's new home.** A delta link to the feature's own
+  `glossary/<term>.md`, `adrs/…` or any other file was re-expressed against the file's old place,
+  which the same archive then moved — `link.unresolved` on the first `validate --all` after a clean
+  archive. A link to a file the archive copies — a glossary term, a flow, a topology document — now
+  lands on its living copy (`glossary/<term>.md`, `architecture/usecases/…`, `architecture/…`); a
+  link to any other file under the feature lands in `features/archive/<FEAT>/`. A feature ADR is
+  never copied into the living tree: it stays with the archived feature, and living documents that
+  cite it point there. A glossary term the archive copies has its own relative links re-expressed
+  for `glossary/` too, so a term citing a service spec or the feature's ADR no longer lands broken;
+  the copy is otherwise byte-for-byte, as before. A link whose text still reaches its target from
+  where it lands keeps its exact spelling.
+- **The documents that stay in the feature keep links that resolve.** The archive moves
+  `features/<FEAT>/` to `features/archive/<FEAT>/` as a plain directory rename, so every relative
+  link out of the feature in the intent, the feature's ADRs, its deltas — any markdown document the
+  rename carried — was one directory short afterwards, and a reader who followed a living
+  document's link into an archived ADR landed on a decision whose own links led nowhere (nothing
+  grades archived features, so nothing said so). The archive now re-expresses those links for the
+  move, in the same commit; a link to another file of the same feature, and any link whose text
+  still reaches its target, is left exactly as written. Each relinked document is an `update` row
+  in `plan`, at its path before the move (`features/<FEAT>/…`), ahead of the `move` row
+  (`--dry-run` included); the text output adds `feature documents: N relinked for
+  features/archive/<FEAT>/` with one line per document, and the snapshot parks each pre-image where
+  the move leaves it (`features/archive/<FEAT>/…`), so `loam unarchive` puts the authored bytes
+  back — archive then unarchive is still a byte-for-byte round trip — and lists them in `restored`
+  (and `discarded`, under `--force`) where they land (`features/<FEAT>/…`). A retried archive and the crash repair find those
+  pre-images across the move. No code, flag or payload key was added, and the snapshot stays
+  version 4: the new rows are literal paths every version-4 reader already restores. **Exit
+  code:** `loam unarchive` now also refuses with `snapshot-stale` (exit 1) when a document the
+  archive relinked was edited under `features/archive/<FEAT>/` since; `--force` puts the authored
+  text back over that edit. Those documents used to move back as they stood.
+- **A document outside the feature that links into it still resolves once the feature is
+  archived.** Another change in flight citing the feature's ADR (`../<FEAT>/adrs/0001-x.md` from its
+  intent), or a living service or fleet ADR citing a decision taken for a change still open, was
+  correct the moment before the archive and `link.unresolved` (an error) on the first
+  `validate --all` after it: the rename took the directory away from under the link, and the
+  archived path the author would have needed did not exist until the archive did. The archive now
+  rewrites those links in the same commit, across the whole link corpus — the fleet's own documents,
+  every service's, every other in-flight feature's, the documents `subsystem move` rewrites for its
+  renames: a term the archive copies into `glossary/` is cited at its living copy, everything else
+  in the feature where it now lives (`features/archive/<FEAT>/…`), and every other link keeps its
+  spelling. A living spec the merge rewrites is relinked from its merged text, so it is still one
+  `plan` row. Each relinked document is an `update` row in `plan` (`--dry-run` included); the text
+  output adds `links into the feature: N document(s) relinked for features/archive/<FEAT>/`, one
+  line per document. The costs are said, not softened: a vouched `spec.md` or `arch.spec.md` the
+  rewrite moves off its stamp is on `revouchOwed` like one the merge moves (`content.stale` follows
+  until its owner re-vouches), and a rewritten route inside a living requirement adds a `note:` line
+  saying a feature that pins it with `Based-On:` reports `delta.baseline-stale` until `loam rebase`.
+  No code, flag or payload key was added. The undo is the snapshot's — each relinked document is an
+  ordinary row, so `loam unarchive` puts the authored bytes back and archive-then-unarchive stays a
+  byte-for-byte round trip. **Exit code:** `loam unarchive` now also refuses with `snapshot-stale`
+  (exit 1) when such a document — another in-flight feature's intent among them — was edited since
+  the archive; `--force` puts the pre-archive text back over that edit. A document whose own feature
+  has been archived or removed since is not drift: `unarchive` leaves it as it is, with a `left:`
+  line in the text output (no `--json` key), rather than recreating a one-file `features/<other>/`.
+- **The undo snapshot no longer breaks a feature's LikeC4 project.** `.loam-before/` stored each
+  pre-image under its living name, so the archived feature held a second `landscape.likec4`: a
+  feature with its own `likec4.config.json`, or rendered alone, failed on duplicate elements, and so
+  did a fleet project that did not exclude `features/`. Snapshot manifests are now **version 4** and
+  store each pre-image as `files/<path>.before`. Version-2 and version-3 snapshots are still read
+  and restored, each under its own layout, and are never rewritten. **An older loam cannot unarchive
+  a feature this version archived** — it refuses with `snapshot-missing`, as it does any layout it
+  does not know — and it cannot repair an archive, unarchive or subsystem move this version was
+  killed in the middle of; finish those with this version, and upgrade every checkout that may run
+  `loam unarchive`.
+- **`loam unarchive` names the generated views it left behind.** It restores what the archive
+  wrote, and `architecture/subsystems.likec4` / `architecture/services.likec4` are not among it, so
+  after `loam subsystem sync` had run on the merged map the undo closed on "the living docs are back
+  to what they said before the archive" over a fleet the next `validate --all` failed
+  (`subsystem.views-stale`). It now prints one `⚠ <path> no longer matches the tree and this map`
+  line per stale file, naming `loam subsystem sync`, under a narrower closing line, and `--json`
+  carries the list as `staleViews` — the key `archive --json` already has, same meaning, absent when
+  nothing is stale.
+- **`loam subsystem move` and `rename` rewrite the relative links the renames would break** — out of
+  every markdown document under a moved directory, and into a moved directory from every other
+  authored document (fleet documents, services, in-flight features; archived features are left as
+  history) — in the same transaction as the renames, and stage them in git with the renames. Each
+  rewritten document is printed as `relinked <path>` and listed in `--json` as `relinked` (always
+  present; `[]` when no link needed rewriting). A rewritten route is still a changed byte, and the
+  move says so in its `warnings` (text: `note:` lines): a `verified` document it relinks no longer
+  hashes to its `content_digest`, so `content.stale` follows (exit 1 under `--strict`) until its
+  owner re-vouches, and a living requirement it relinks moves the digest a feature in flight may
+  have pinned with `Based-On:`, so that feature reports `delta.baseline-stale` until `loam rebase`.
+  Before this release the same move left those links `link.unresolved` instead. **Exit code:**
+  `move-uncommitted` now also refuses (exit 1) when git reports an uncommitted or untracked
+  document OUTSIDE the moved directories that the move would relink — an in-flight feature's work
+  in progress included; it used to proceed and leave the link broken. A commit killed after its
+  renames now recovers a relinked document from where the rename took it instead of refusing it as
+  edited.
+
+### Changed — `loam status` says where a feature stands in words, with the claims counted
+
+No code was added or renamed, and no exit code changed. The `stage` values (`missing`, `blocked`,
+`draft`, `ready`, `done`) are untouched; what changed is that the human view no longer prints them
+bare. `ready` means the documents are written and pass the shared checks — nothing about code or
+evidence — and `loam status FEAT-101 — ready` over a feature nobody had built or verified read as
+"ready to ship"; `done (archived)` over a feature that was never verified read as "shipped and
+checked", when archive checks documents and nothing else.
+
+- **The header is a sentence:** `loam status FEAT-101 (Payment splitting): docs ready — nothing
+  verified yet (0 of 19 claim(s) answered)`; for an archived feature `archived — never verified (no
+  verification record)`, `archived — verified (…)` or `archived — attested, not verified: …`. The
+  machine value moves to its own `stage` row, which names `loam explain <stage>`.
+- **The artifact table says what each row means:** `written`, `not owed`, `missing`, `has errors`,
+  `blocked`; the verification row `none yet`, `open`, `attested`, `verified`, `stale`,
+  `unreadable`. The `verification` row with no record says how many claims there are to answer.
+  `coherence` ends with `N stop it (validate --feature or archive refuses on each)` — every error
+  and every gating warning — instead of `N gate archive`, which counted only findings carrying
+  `gates` and so read 0 over a feature archive refuses for an unknown service. The `checks.gating`
+  payload value is unchanged.
+- **The fleet form says less than the feature form, on purpose:** it grades nothing, so a verified
+  feature reads "its own status says whether archive will take it", not "ready to archive"; and a
+  feature behind an interrupted commit reads as blocked by the commit even when it also waits on
+  another feature.
+- **`next[]` statements (prose, not codes):** `next.archive` no longer says a feature "ships once
+  everything above is done" — it says archive checks only the documents, not the code and not the
+  verification record; its clean form says "archive it" instead of "ship it". `next.archived` no
+  longer says the feature "shipped": it says what archiving did and whether it was verified. The
+  fleet form's `next.feature` says the stage in the same words (`FEAT-101 (Payment splitting): docs
+  ready — nothing verified yet (no verification record).`) instead of `FEAT-101 is at 'ready'.`, and
+  `next.elided` counts what it left out by code.
+- **Additive payload keys:** `feature.title` and `checklist` (`{claims}` — how many claims the
+  feature's checklist asks now; `null` for an archived feature) on `loam status <FEAT> --json`;
+  `features[].title` and `serviceSteps[]` on `loam status --json`; `title` on
+  `loam show <FEAT> --json` and on `loam list --json`'s `features[]`. The title is intent.md's
+  `title:`, else its first `# ` heading without the feature id, else `null`.
+- **Feature rows name the change:** `loam status`, `loam list` and `loam show <FEAT>` print the
+  intent title beside the id. An intent.md loam cannot read is no title, never a refusal.
+- **Help text:** `loam verify` is described as "Check a feature against its own promises: derive the
+  claims, record the answers with evidence" and `loam archive` as "Merge a finished feature's deltas
+  into the living specs + model, then archive it (checks the documents, not the code)" — neither
+  says "shipped" any more. The `validate --all` scorecard's features row glosses `ready` and `done`.
+
+### Changed — `loam status` lists the features in flight before any service's adoption work
+
+No code, flag or exit code changed; the ORDER of the fleet form's `next[]` did, and one payload
+key was added. The per-service rungs (`next.adopt`, `next.complete-service`, `next.revouch`) used
+to lead the list, so on a fleet mid-adoption the cap of ten filled with them and elided the one
+feature in flight as "more step(s) of the same kinds".
+
+- **Order:** `next.recover-commit` (outside the cap), then `next.adopt-bound` or the first-hour
+  ladder, then every feature (`next.feature`, `next.archive`), then the per-service rungs — the
+  bound service's own still first among them — then `next.elided` and `next.fleet-gate`. An agent
+  reading `next[0]` in a docs repo with a feature in flight now gets that feature, not an adopt.
+- **`serviceSteps[]`** (additive, `loam status --json`): every per-service rung, uncapped, grouped
+  by code — `{code, services, command}`, `command` being the first service's.
+- **The human view folds each per-service code into one counted line** under the features —
+  `next.adopt ×12: 12 services with no spec.md — …: a, b, c, …, +6 more.` — and only says
+  something was left out when features were.
+
+### Changed — a repository bound to a service its feature introduces is not told to adopt it
+
+No code was added. In a service repository whose `loam.json` names a service that exists only in
+an active feature's `specs/<service>/`, `loam status` led with `next.adopt-bound` →
+`loam adopt --service <id>` — adopting code that does not exist yet. It now leads with that
+feature's `next.feature` (`loam status <FEAT> --json`) — one per feature that introduces it —
+saying the service joins the living docs when one of them archives, and does not list those
+features again. A bound service no feature
+introduces gets `next.adopt-bound` as before.
+
+### Changed — `loam doctor` agrees: a service a feature introduces is not something to adopt
+
+No code was added and no exit code changed. In the same state — a service repository whose
+`loam.json` binds a service that exists only in an active feature's `specs/<service>/` — `loam
+doctor` still filed `doctor.service-unknown` with "Run `loam adopt --service <id>` to onboard it".
+The finding keeps its code and its `warning` severity (the binding still names nothing under
+`services/`, and `healthy` does not move), and now says which feature introduces the service and
+that it is not in the living docs until that feature archives. Its `fix` names `loam status <FEAT>`
+and no longer tells anyone to adopt.
+
+- **Human view:** the `binding` row reads `payment-split-service · introduced by FEAT-101 (in
+  flight)` instead of `· unknown`, listing every introducer when more than one feature introduces
+  the service.
+- **`--json` (additive):** `currentService.introducedBy` — the introducing features' ids, ordered
+  by id — present only when an active feature introduces the configured service.
+  `currentService.status` stays `unknown`.
+- `loam explain doctor.service-unknown` and the `loam-codes` page of `loam instructions` describe
+  both states and both fixes.
+- A bound service no feature introduces gets the adopt advice, byte for byte, as before.
+
+### Changed — `loam validate` in that repository validates the feature that introduces its service
+
+No code was added. In the same state, a bare `loam validate` refused with `✗ No service directory
+at services/payment-split-service. Did you mean: payment-service?  (service.unknown)` and exited 1.
+It treated the newest service in the fleet as a typo of an older one, so that repository's CI could
+not pass until the feature archived. A service a feature introduces has no `services/<id>/` yet.
+Its documents are the feature's `specs/<id>/`, so the run now validates each introducing feature
+instead. That is the same grade `loam validate --feature <FEAT>` gives, target for target, and the
+exit code follows it: `0` when the feature is valid, `1` when it has errors. `--strict` and
+`--errors-only` work as before.
+
+- **Human view:** two lines above the report say what was validated and why —
+  `payment-split-service   introduced by FEAT-101 (in flight) — not in the living docs until it
+  archives` (the header `loam show payment-split-service` prints), then `validating FEAT-101
+  instead: its specs/payment-split-service/ are this service's documents until then`.
+- **`--json` (additive):** `boundService` — `{ id, living: false, introducedBy }`, the same keys
+  `show` and `steps` use for this state — present only on such a run. `targets` then holds the
+  features and no service, and the `summary` counts no services.
+- **Naming the service** with `--service <id>` or the positional still targets a service, so it is
+  still `service.unknown` at error and exits 1. The message now names the feature in place of a
+  near-miss: ``No service directory at services/payment-split-service: FEAT-101 introduces it, and
+  it is not in the living docs until FEAT-101 archives. Until then its documents are FEAT-101's
+  specs/payment-split-service/ — run `loam validate --feature FEAT-101` to validate them.``
+- `loam explain service.unknown`, its row in the `loam-check` fix table (the text `--json`'s
+  `fixes` carries) and the `loam-codes` page describe both states.
+- A name no active feature introduces keeps today's `service.unknown` message and near-miss,
+  unchanged.
+
+### Added — `loam explain` defines the words loam prints, and a finding page says which command reports it
+
+No code was added. `loam explain` knew six concept terms and answered `unknown-target` for the
+words a person meets first in loam's own output.
+
+- **Seventeen new concept terms** (23 in all), with aliases: the stages — `stage` (`missing`,
+  `blocked`, `draft`), `ready`, `done`, each saying what it does NOT mean (`ready` is documents
+  only; an archived feature is `done` whether or not anybody verified it); `claim` and each claim
+  kind — `service.exists`, `api.exposes`, `event.declares`, `c4.calls`, `scenario.tested`; the
+  verdicts — `verified` (`unverified`), beside the existing `attested`; the `loam tasks` words —
+  `unit`, `frontier`, `describe`, `generate`, `implement`; `coherence` (`gates`, `gating`); and the
+  maturity ladder — `maturity` (`empty`, `partial`, `documented`, `sourced`). An alias names the entry
+  that answered it. **Exit code:** 0 where it was 1 (`unknown-target`) for each new term and alias.
+- **The bare `loam explain` listing groups the terms** under four headings (feature stages, the
+  done-check, the work packet, the documents). `--json` `terms[]` keeps its row shape; it has 23
+  rows instead of 6, in the listing's grouped order, so the six existing terms are at new positions.
+  `loam explain --help` and the MCP `explain` tool's `subject` description list the new terms.
+- **A finding page's header says which command reports the code** — "when `loam validate --feature
+  <FEAT-id>` reports it — warn" — instead of `[--feature <FEAT-id>] (warn)`, which read as an
+  optional flag. `--json` `entries[].scope` is unchanged. The `next.*` entries say what the steps
+  now say: archive checks documents only, and the fleet list leads with the features.
+
+### Changed — `loam show`, `loam context` and `loam steps` answer for a service a feature introduces
+
+No code was added. A service an active feature introduces (`features/<FEAT>/specs/<svc>/` exists,
+`services/<svc>/` does not yet) was refused by all three as unknown, while `loam tasks` listed work
+for it on the same tree.
+
+- **`loam show <svc>`** prints the introduced-service view: which feature introduces it, its delta
+  documents, requirement counts, operations, and the `loam show`/`delta`/`tasks` commands to run.
+  `--json` is `{type: "service", id, living: false, introducedBy[], introductions[]}`, each
+  introduction carrying the keys of `show <FEAT>`'s `services[]` plus `requirements`, `archSpec` and
+  `next[]`. **Exit code:** 0 where it was 1 (`unknown-target`).
+- **`loam context <svc>`** briefs from the introducing feature's delta, saying the service is not in
+  the living docs yet. `--json` adds `living: false` and `introducedBy[]`, and `path` is the
+  feature's `specs/<svc>/`. `--feature` naming a feature that does not introduce it refuses
+  `unknown-service`. **Exit code:** 0 where it was 1 (`unknown-service`, or `invalid-option` when the
+  feature's `specs/` directory name is not a legal service id). **Code change:** with two
+  introducing features and no `--feature`, the refusal is now `invalid-option` naming both, where it
+  was `unknown-service` — a script that read `unknown-service` as "no such service" sees the new
+  code for this one case. Its "did you mean" hint now includes introduced services.
+- **`loam steps --service <svc>`** (or the bound service) inventories the step phrases of the
+  feature's spec deltas. `--json` adds `living: false`, `introducedBy[]` and `specs[]`. **Exit
+  code:** 0 where it was 1 (`unknown-target`, or `invalid-option` when the feature's `specs/`
+  directory name is not a legal service id).
+- Payloads for living services, and the refusals for a name nothing introduces, are unchanged.
+
+### Changed — `loam tasks` reads as a to-do list, and a service repository sees its own slice
+
+No code or flag was added.
+
+- **The human view** groups units by service and then by requirement (its file printed once), and
+  says each unit as an action — "make scenario '…' pass, then record the run", "generate the test
+  for scenario '…' (loam gherkin <FEAT>)", "expose operation '…'", "call '…' on <svc>" — keeping the
+  unit id on every row. The header says in words what `record` and `stamps` mean, and the frontier
+  line leads with the next unit's action. `--next` leads with the action and warns when this
+  repository cannot see whether the scenario's test was generated; the Given/When/Then lines are
+  unchanged.
+- **`--service` lists every unit**; the whole-feature view still caps each service at 12, and now
+  points at `loam tasks <FEAT> --service <id>` instead of `--json`.
+- **Behaviour change:** in a repository whose `loam.json` names a `service`, `loam tasks <FEAT>`
+  without `--service` narrows to that service when the feature touches it. Under `--json`, `service`
+  is the bound id; `units`, `counts`, `frontier`/`frontierElided`, `contracts` and `size.calls`
+  cover that service only; and `waitingOn` appears. The generated-suite stamps that tell `generate`
+  from `implement` are read from this repository alone, so other services' steps in a whole-feature
+  view were never about their repositories. Pass `--service <id>` for another service; a docs repo,
+  and a feature that does not touch the bound service, get the whole feature as before.
+
+### Changed — `loam validate`'s human report marks every error, names files relatively, and leads with what matters
+
+No code, severity, subject, payload key or exit code changed; `--strict` and the summary counts are
+the same.
+
+- **`service.no-model` and `service.unknown` print with ✗** — they printed with no marker.
+- **Messages name files by repo-relative `/` paths** instead of the absolute path of the machine
+  that ran the check: `service.unknown`, no-model, no-spec, no-openapi, no-asyncapi, an unreadable artifact
+  (`service.unreadable` / `feature.unreadable`) and `health.dependency-unmodelled`. The same
+  `message` strings in `--json` change with them. A path outside the docs repo keeps its absolute
+  spelling.
+- **`sources.unverifiable-from-here` prints ○, not ✓** — that check did not run here. It stays
+  severity `ok`.
+- **On `--all`, a warning or error more than three services raise once each prints once**,
+  followed by one line counting them (`same code ×N on M services: …`, capped, `+K more`). A
+  service raising the code more than once, and a finding carrying details, still print in full;
+  every finding is still in `--json`.
+- **`--all` opens with the counts and an "errors by code" index, then the feature blocks**, then the
+  landscape and per-service findings; an interrupted-commit finding still leads and the footer still
+  closes the report.
+
+### Fixed — on Windows, a rolled-back write takes back the directories it created
+
+No code, flag or payload key was added. On Windows under Node 24, a command that failed and rolled
+back — `loam archive` most visibly — answered `merge-failed` ("rolled back, nothing was merged")
+and still left the directories it had made standing: an empty `features/archive/`, or an empty
+`services/<new-service>/` that names a service the merge never added. Node reports the directory
+`mkdir` created in the `\\?\C:\…` spelling, and the rollback, comparing that with the plain
+spelling, found nothing inside it to remove. Those directories are now removed on Windows as they
+already were on Linux and macOS; a directory something else has put a file in is still left alone.
+
+## [0.2.0-alpha.9] - 2026-10-20
+
+The first publish since `0.2.0-alpha.7`. `0.2.0-alpha.8` was tagged but never reached npm (its
+release run failed at `npm ci` on a stripped lockfile), so a repository upgrading from alpha.7 takes
+alpha.8's section below as well as this one. Still a prerelease on the `alpha` line.
+
+Most of it is fixes. `loam archive` merges into a landscape written in any form LikeC4 parses —
+several model blocks, markdown strings, split heads, hyphenated ids — and no longer writes a wrong
+merge at exit 0 for the shapes listed under "Fixed — `loam archive` merges into a landscape…",
+which alpha.7 did. Consumers are counted once, by one index, so `loam archive`, `loam validate` and
+`loam diff` agree; the PR gate sees a changed schema, an edited `op` on an edge and a caller drawn
+with no `op`; `loam gate --since` keeps an archived feature in view; the trust readouts show stale
+vouches; a waiting writer no longer deletes the next writer's lock.
+
+Several entries change an exit code, listed in each: refusals that are new (an overwrite or
+retirement a consumer still names, a delta reviving a retired operation, an unreadable consumer
+document) and refusals that were false and are gone. A federated verification record is now one
+file per service, and an older loam does not read it: upgrade every repository that records or
+gates a feature together. New: `loam list suites`, `loam new --modifies`, `loam gate --since`,
+`loam_adopt` on MCP; six new stable codes — `openapi.op-revived`, `asyncapi.slot-revived`,
+`next.revouch`, `frontmatter.owner-mismatch`, `diff.op-modified` and `diff.message-modified`.
+
+### Changed — one consumer index: `loam archive`, `loam validate` and `loam diff` agree about who still consumes an operation or a message
+
+No code or flag was added; one additive `--json` key on two existing codes. Who still consumes what
+a change takes out was answered three ways — the coherence gate (`openapi.remove-op-consumed`,
+`asyncapi.remove-message-consumed`), `loam diff`'s victims (`diff.op-removed-consumed`,
+`diff.message-removed-consumed`, the `-deprecated`/`-modified` details, `diff.consumer-added` /
+`diff.consumer-removed`) and `loam archive`'s `openapi.op-modified` / `asyncapi.message-modified`
+warnings — and the three copies read different documents. They are one index now; SCHEMA.md's
+"Who still consumes it" states the rules.
+
+- **More consumers are found, so more removals are refused:**
+  - **Edges come from the whole `architecture/` project**, not `architecture/landscape.likec4`
+    alone, for the gate as for `loam diff` and the archive's overwrite warnings: an edge with `metadata { op }` (or `consumes`) drawn in
+    `architecture/calls.likec4` or in a use-case document counts. The gate passed such a removal
+    and the next `validate --all` reported `spine.op-undefined` on the edge. Where only a sibling
+    document fails to parse, the map file's own edges still count.
+  - **The gate names use-case hops** attributed to the operation (or backed by a `consumes` edge),
+    as `loam diff` already did.
+  - **An `arch.spec.md` `Operations:` line** of another service counts, as a spec.md one does —
+    for the gate, `loam diff`'s victims, `diff.consumer-added` / `diff.consumer-removed` and the
+    archive's overwrite warnings. So an
+    operation's `diff.consumer-added` / `-removed` is not reported while the consumer's
+    `arch.spec.md` cannot be read on the other side, as it never was over an unreadable `spec.md`.
+    The consumer's own `openapi.yaml` does not suppress it: an unreadable contract proves no
+    ownership, so the line counts on that side too. The exception is a line whose join exists only
+    because that contract did not parse on one side, while on the other side it reads and defines
+    the id: there the line names the consumer's own operation, and only the contract's readability
+    changed. No `diff.consumer-added` / `diff.consumer-removed` is reported for it — before, one per
+    provider of the id, each counted in the `--json` summary's `added` / `removed`. The contract's own
+    `unreadable[]` entry is still reported, and `loam diff` still exits 1 on it.
+  - **The provider's own `spec.md` requirements count for a marker retirement too**, as they do for
+    the overwrite of the entry below: one still naming the retired operation after the merge (a
+    second one beside the REMOVED requirement) archived at exit 0 and left `spec-api.op-undefined`.
+    Its `arch.spec.md` `Operations:` lines count for neither shape: `validate` grades such a line in
+    spec.md only, so one in arch.spec.md strands nothing. An edge the provider draws to itself
+    counted already, and still does — the spine grades it like any other.
+    `loam diff` and the archive's overwrite warnings still leave the provider's own documents out:
+    they name who ELSE is affected.
+  - **On the event axis the provider's own `Publishes:` lines count**, as the merge would leave
+    them. A message slot re-keyed to another name, or a send operation turned to receive, while the
+    provider's requirement still publishes the message, archived at exit 0 and the next
+    `validate --all` reported `spec-event.message-undefined`; it is `asyncapi.remove-message-consumed`
+    now. So do its own `publishes` edges, which the spine grades on their source: a full retirement
+    over a living `paymentService -> billingService { metadata { publishes '…' } }` archived at exit
+    0 and left `spine.message-undefined` on the provider. The remedy names "drop or redraw its
+    publishes edge".
+  - **Fail closed**: a spec the merge refuses to apply — a malformed `Requirement-ID:` in the
+    living spec or the delta — no longer answers "no consumers". The living requirements count,
+    plus every requirement the delta ADDS or MODIFIES.
+  - **A consumer document loam cannot read refuses the removal**, as the gate did before it asked
+    one index: another service's `spec.md` or `arch.spec.md` that does not decode as UTF-8, the
+    provider's own `spec.md` (either spec file, for a message), or a service id two directories
+    claim. `openapi.remove-op-consumed` /
+    `asyncapi.remove-message-consumed` name each in `details[]` and say the gate could not check —
+    never that the fleet still consumes it. An edge drawn with no `metadata { op }` and a contested
+    use-case hop still never refuse; `loam diff` lists them as doubts, as before.
+  - **`loam diff` counts only a service that SENDS a message as still producing it.** A removed
+    message another service declares only with `action: receive` — a consumer's own declaration,
+    which validate requires — was `diff.message-removed` (warn), "still declared by" that consumer,
+    while the gate refused the same removal and the next `validate --all` reported
+    `spine.message-unproduced` there. It is `diff.message-removed-consumed` now, naming the gate's
+    consumers; the warning for a message another service does send reads "still sent by".
+- **Fewer refusals where the consumer was false or already retired:**
+  - **Another service's `Operations:` line naming an id its own contract defines** names its own
+    operation, and is no consumer (gate, `loam diff`, `diff.consumer-added` / `-removed`, the
+    archive's overwrite warnings): shared
+    ids such as `healthCheck` no longer refuse a rename, and `--approve` is no longer the only way
+    past a fleet `validate --all` calls clean.
+  - **Read after the feature's merge**: a consumer requirement the same feature MODIFIES to drop
+    the id, or REMOVES, no longer counts — another service's included, which is the remedy the
+    refusal itself names.
+  - **A message another service would still send after the merge strands no consumer.**
+    `asyncapi.remove-message-consumed` counted every `consumes` edge, `Consumes:` line and use-case
+    hop of a message whoever sent it, so retiring it from one of two senders was refused over the
+    other sender's consumers. Its remedy said to drop that sender's own `consumes` edge. Meanwhile
+    `loam diff` reported the same removal as `diff.message-removed` (warn), "still sent by …", and
+    the next `validate --all` was clean. Now a consumer refuses only while no service would send the
+    message after this feature's merge. The senders are read as the merge leaves them: a service
+    the feature carries an event delta for sends what its merged contract would (the delta itself
+    where it creates that contract), so moving production to another service in the same feature
+    passes, and a feature that retires the message from every sender is still refused. An unreadable contract never counts as
+    a sender. Beside another sender, the provider's own `Publishes:` lines, its own `publishes`
+    edges and its own unreadable spec files still refuse; another service's unreadable spec file,
+    or an id two directories claim, does not. This predates the one index: the gate behaved the
+    same before it. The message is reworded to say which case applies. With no sender left it reads
+    "no readable contract would still send it after this merge" and adds the route "keep another
+    service sending it". With a sender left it names the senders, lists only the provider's own
+    documents, and gives only their remedy.
+  - **An `#external` element that publishes the message keeps its consumers produced too**, for
+    the gate and for `loam diff` as for `validate`. Both counted only senders inside the fleet, so
+    retiring a message from its only fleet sender was refused while an `#external` element still
+    published it (an edge from it with `metadata { publishes }`), and after `--approve` `loam diff`
+    reported `diff.message-removed-consumed` (error) — while `spine.message-unproduced` accepts such
+    a producer and the next `validate --all` was clean. Now the outside producer counts as a
+    sender, read off the living `architecture/` project with validate's own rule: only while the
+    project parses, and not from an edge the feature's own C4 delta draws. The gate asks the rule
+    over the service directories as the merge leaves them, so an element the same feature makes a
+    service — a `specs/<id>/` directory for the id the element, or the element it is nested in,
+    resolves to, which the archive turns into `services/<id>/` — no longer counts, and the
+    retirement is refused, as the next `loam diff` and `validate --all` would read it; `loam diff`
+    asks over the directories as they stand. `loam diff` reports
+    `diff.message-removed` (warn), "still sent by `<title>` (#external)", and a refusal for the
+    provider's own documents, which it still does not excuse, names it the same way. With no sender
+    left, the refusal now also says "nor does an #external element publish it", and its route
+    reads "keep another service sending it (…) or an #external element publishing it (a publishes
+    edge from it in the living architecture/ project; one whose element this feature's
+    specs/<service>/ makes a service no longer counts)". This predates the one index too.
+  - **`openapi.remove-marker-missing` is owed only while there is a living operation to retire**:
+    not for an id the service's living contract does not define (a consumer's REMOVED requirement
+    naming another service's operation), and not for one the delta already replaces at its method
+    and path (no marker could be written there). A living `openapi.yaml` that does not parse proves
+    neither, so the marker is still owed there, as before. The overwrite's "REMOVE the requirement"
+    route can now be followed; its message says a REMOVED requirement owes no marker there.
+    `asyncapi.remove-marker-missing` likewise skips a message the merge already takes out.
+- **`details[]`** (additive) on `openapi.remove-op-consumed` and `asyncapi.remove-message-consumed`:
+  the consumers, one per line, in the order `loam diff` lists the victims of the same removal.
+- **Messages reworded**: the remedies name the `architecture/` project instead of
+  `architecture/landscape.likec4`, and say a requirement is retired in the feature's
+  `specs/<service>/` delta; `diff.op-removed`'s no-consumer sentence reads "no current edge,
+  requirement or use-case hop names it".
+- **Exit code:** where a consumer is newly found, `loam archive` exits 1 (`not-coherent`) without
+  `--approve`; `loam validate --feature`, `loam validate <FEAT>` and `loam validate --all` (for every
+  active feature in that shape) exit 1; `loam status` counts the finding as gating; `loam show
+  <FEAT> --json` reports `review.readyToArchive: false`; and `loam diff` exits 1
+  (`diff.op-removed-consumed` / `diff.message-removed-consumed`, `breaking: true`) where a removal
+  now has a victim — a removed message whose only other declarer receives it included, which exited
+  0. Where another service's spec file does not decode, `loam validate --feature`
+  reports `openapi.remove-op-consumed` / `asyncapi.remove-message-consumed` naming the file where it
+  reported `feature.unreadable`, at exit 1 as before, and `loam archive` exits 1 as before. Where
+  two directories claim a service id, or the provider's own `spec.md` does not decode (either spec
+  file, for a message), `loam
+  archive` and `loam validate --feature` exit 1 for the removal whatever those documents say —
+  before, 0 unless a copy the gate could read named it — until the document reads or `--approve` is
+  passed. Where a refusal was false or the consumer is retired in the same feature, each
+  of those exits 0 for that shape unless something else gates. That includes a message retired from
+  one sender while another service would still send it after the merge, or while an `#external`
+  element still publishes it and the feature does not make that element a service, where only
+  consumers were named: `loam archive`, `loam validate --feature`, `loam validate <FEAT>` and `loam validate
+  --all` exited 1 and now exit 0, `loam status` no longer counts it as gating, and `loam show
+  <FEAT> --json` no longer reports `review.readyToArchive: false` for it. `loam diff` reports
+  `diff.op-removed` (warn) where its only victim was a same-id requirement, and
+  `diff.message-removed` (warn) where an `#external` element still publishes the removed message —
+  it exited 1 (`diff.message-removed-consumed`, `breaking: true`) and now exits 0 unless something
+  else fails. `--approve` overrides
+  every one of these refusals as before. `--strict` changes nothing here beyond that: every finding
+  in this entry is an error, or is unchanged.
+
+### Fixed — `loam instructions loam-spine` says what `loam rebase` pins for a revived quote
+
+The page said `loam rebase` "pins neither shape". That has been false since rebase began grading
+the delta it will write. Rebase never pins a retired operation as new, but it does repin a quote
+of an address a move vacated over the operation that lives there now, and it reports the revival
+that edit makes. The page now says so, in line with the `loam-codes` command map, WORKFLOW.md
+and SCHEMA.md.
+
+### Fixed — an operation with no `operationId` is a slot like any other
+
+No code, flag or payload key was added. The OpenAPI reader used to drop an operation written
+without an `operationId`. It now keeps it by its method and path, never by an id: requirements,
+edges and removal markers still cannot name it, and it gets no finding of its own. The checks that
+work by slot now see it:
+
+- **`openapi.op-revived` names it.** When a quote lands where such an operation lives, the message
+  says `<METHOD /path> now holds an operation with no operationId, and archiving this delta
+  replaces it there`. Its move-back remedy adds that, if that operation is to stay, the same delta
+  must define it at another address. The message no longer calls that address one "the living
+  contract no longer has". Followed as it used to read, the remedy led to an archive that deleted
+  the operation with nothing naming it.
+- **`loam rebase` and `loam validate` agree about a pin over it.** Rebase always pinned against
+  whatever stood at the slot, but validate refused that pin with `openapi.baseline-invalid` ("no
+  operation at that slot").
+- **Pins are now required at these slots.** An unpinned quote over such an operation counts into
+  `openapi.baseline-missing` (warn, gates archive), and so does an unpinned delta operation without
+  an `operationId` over a living one. Their pins are graded like any other (`-stale`, `-invalid`).
+  **Exit code:** `loam archive` now exits 1 (`not-coherent`) on either shape until `loam rebase`
+  pins it, or `--approve` merges unpinned. `openapi.baseline-missing` is a warning that gates:
+  `loam validate` exits as before on it, except `--strict` (and `--all --strict`), which fails on
+  any warning and so now exits 1; `loam status` counts it as gating, and `loam show <FEAT> --json`
+  reports `review.readyToArchive: false` until the pin is written.
+- **A pin on such an operation where nothing lives is `openapi.baseline-invalid` (error)**, as it is
+  for a named operation (rebase never writes one; a malformed pin on such an operation is refused
+  the same way). **Exit code:** `loam validate --feature`, `loam validate <FEAT>` and `loam validate
+  --all` (for every active feature carrying one) now exit 1 on it, where they exited 0 with no
+  finding; `loam archive` exits 1 (`not-coherent`) without `--approve`; `loam status` counts it as
+  gating; `loam show <FEAT> --json` reports `review.readyToArchive: false`.
+- **`openapi.remove-op-consumed`** also fires when the delta defines an operation with no
+  `operationId` where a consumed one lives. Before, a delta holding only such an operation upserted
+  over the consumed one with no finding of any kind.
+
+### Changed — `loam archive` refuses an overwrite that takes a consumed operation out of the contract
+
+No code, flag or payload key was added: an existing code covers a second shape.
+
+- **`openapi.remove-op-consumed` (error, `--approve` overrides) now also fires for an overwrite.**
+  A feature's `openapi.yaml` defines another operationId at the method and path where a living
+  operation lives, and the contract the archive would write then defines the living one nowhere.
+  The merge replaces it there with no removal marker naming it, so before this only the advisory
+  `api.op-unconsumed` fired, the archive passed without `--approve`, and the next `validate`
+  reported `spine.op-undefined` / `spec-api.op-undefined`. The consumers are a removal's — the one
+  consumer index of the entry above — including the provider's own `spec.md` requirements as the
+  merge would leave them: one the feature MODIFIES to name the new operation, or REMOVES, no longer counts. The
+  message names what replaces the operation and where, and says to define it at another address in
+  the same delta if it is to stay.
+- **Exit code:** on this shape `loam archive` now exits 1 (`not-coherent`) without `--approve`,
+  and `loam validate --feature`, `loam validate <FEAT>` and `loam validate --all` (for every active
+  feature in this shape) exit 1. `loam status` counts it as gating, and `loam show <FEAT> --json`
+  reports `review.readyToArchive: false` until it is fixed or archived past with `--approve`. With
+  `--approve` the archive merges as before and lists the finding in `overridden[]`.
+- **`c4-api.op-removing`** now also fires for a new tagged edge onto an operation the delta
+  replaces that way.
+- An overwrite of an operation nothing names is unchanged: `api.op-unconsumed` stays advisory. On
+  the event axis `asyncapi.remove-message-consumed` already graded the simulated merge's sent
+  messages, so a channel, operation or message slot redefined under another identity was caught
+  like a retirement for its OTHER consumers — but not for the provider's own `Publishes:` line,
+  which the consumer-index entry above adds.
+
+### Fixed — `loam archive` merges into a landscape written in any form LikeC4 parses
+
+No code, flag or `--json` key was added or changed. Each case below is a landscape (or a delta)
+that `loam validate --all` called valid and that `loam archive` refused with `merge-failed`, nothing
+written — or, where the case says "exit 0", merged wrong and wrote; each now merges as LikeC4
+reads it.
+
+- **A landscape with more than one top-level `model { }` block.** The splice map read only the
+  first block, so every declaration in a later one was invisible and archive refused with
+  "declares '<id>' in a form placement cannot locate — most often two declarations sharing one
+  line" about a declaration on a line of its own. Every block is read now. An addition anchored to
+  a living element — nested in it, joining its service's neighborhood, or joining its source's
+  edges — lands in that element's block; an unanchored one lands in the first block's trailing
+  region, where it landed before. A one-block map is placed byte for byte as before, and archive
+  order still does not change the bytes. The same reading fixes three neighbours: a delta written
+  in two `model { }` blocks (its second-block additions were "cannot locate … in delta.likec4"), a
+  service `model.likec4` whose `extend <fqn> { }` frame sits in a later block (the merge minted a
+  second frame in the first block, or re-added a container the model already declares there), and
+  `loam validate --all --base`, which did not grade a call edge the branch edited in a later block.
+- **A declaration split across lines.** LikeC4's newlines are hidden tokens, so `name =` with its
+  kind on the next line, a bare name above `= kind`, a kind above the name it declares, a title on
+  the next line, a `/* … */` comment spanning a line break, an edge broken around its arrow, and an
+  edge's `#tag` on the next line are all one statement — and the splice map, reading one line per
+  statement, could not see them. Worse, `name = kind 'title'` with its `{` on the NEXT line read as
+  a bodyless element: an addition anchored after it landed between the head and its body and took
+  that body — description, children, `metadata { service }` binding — for its own, in a merge that
+  parsed and was written (exit 0). The body stays with its element now.
+- **An `extend <fqn> { }` frame written in the landscape itself, with an edge inside it.** An
+  edge the feature added, anchored to the frame's edge, was spliced INSIDE the frame — a scope, so
+  its names re-resolved there: the delta's `zulu -> beta` landed in `extend alpha { beta = … }` as
+  an edge into alpha's own `beta` container, in a merge that parsed and was written (exit 0). It
+  lands outside the frame now. Elements inside such a frame were already read correctly.
+- **A hyphenated id (`entity-service = …`) and a dot-kind edge (`a .async b`).** LikeC4's
+  identifiers may carry hyphens and a declared relationship kind may be written as `.kind`; the
+  splice map read neither, so such an element was "in a form placement cannot locate" and such an
+  edge made the relationship count disagree.
+- **A `link` (or `icon`) URI followed by more code on its line.** LikeC4 reads `https://…` and a
+  relative `./…` path as one token; the splice map read its `//` as a comment that ran to the end
+  of the line, so `x = kind 'X' { link https://… }` lost its closing brace and archive refused with
+  `landscape.likec4 has no model block`. The URI is a token wherever it sits: a `link` or `icon`
+  alone on its line ends there, and the child or edge declared on the line below is its own.
+- **A markdown string (`'''…'''` or `"""…"""`) whose prose holds an apostrophe or an odd number
+  of quotes.** The splice map read the triple as three ordinary quotes, so the first `it's` in a
+  long `description` ended the string and the rest of the file was read inside out — a map with
+  one such description above its model had no model block at all, and archive refused with
+  `landscape.likec4 has no model block`.
+- **A delta edge whose body holds a key or tag containing `op`, `publishes` or `consumes`.** The
+  splice map read those keys anywhere in the edge's body, and took a hyphen for the end of a word,
+  so `op-version 'v2'` above `op 'cancelOrder'` read as op `v2`, and a `#op-critical` or `#op` tag
+  as an op naming the description below it. The edge then matched none of the delta's statements
+  and archive refused with "cannot locate the '<a> -> <b>' relationship in delta.likec4". A key is
+  read whole now, and `op`, `publishes` and `consumes` only from `metadata { }`, which is where
+  LikeC4 reads them. The same misreading hid such an edge from `validate --all --base` (below).
+- **A bare carriage return (`\r` with no `\n`) between two statements.** LikeC4 breaks a line at
+  `\r` as well as `\n`, and the splice map broke only at `\n`. A statement therefore ran on over
+  a bare `\r` into the next one, and a `// comment` ran on over it and hid the next declaration.
+  Two elements, two edges or a property and a child on either side of a bare `\r` were refused as
+  "in a form placement cannot locate". A bare `\r` ends the statement and the comment now. A CRLF
+  map reads exactly as before.
+- **An addition anchored to a declaration whose line goes on with more code.** Placement put an
+  addition on the line after its anchor. When the next declaration opened a multi-line body on the
+  anchor's own line (`alpha = … { … }  beta = … {`), that next line was inside beta. An element
+  bound to alpha's service was then written inside beta as its child, in a merge that parsed and
+  was written (exit 0). A block comment opened on the anchor's line and closed on a later one
+  swallowed the addition the same way. The addition now lands right after its anchor whenever
+  code, or a block comment the line does not close, follows the anchor on its line. Two archives
+  anchored to the two declarations on such a line also write the same bytes in either order now;
+  before, whichever ran second landed above the other. A comment trailing the anchor changes
+  nothing: the addition lands on the next line, as before — unless a bare `\r` ends that `// comment`
+  and the next declaration follows it on the same line, which counts as code following the anchor.
+- **A bodyless declaration with a comment trailing it on its line.** A parent such as
+  `api = container 'API' // the api` that gained its first child got its `{` inside the comment,
+  and archive refused: the merged landscape "would not parse". The body now opens before the
+  comment, which then trails the new closing brace. A block comment that closes on a LATER line
+  was worse: the splice map ended the declaration inside it, so a child it gained, or an element
+  or edge anchored after it, was written inside the comment, in a merge that parsed and was
+  written (exit 0). The declaration now ends before such a comment. A comment that closes on the
+  declaration's own line keeps its place, and the bytes come out as before.
+- **A delta whose feature tag sits in a tag list with a separator.** LikeC4 reads a tag list as
+  `#a #b, #c;`: one or more tags, then comma groups, then an optional `;`. Stripping the feature's
+  own tag left `#FEAT-1, #x` as `, #x` and `#FEAT-1;` as a bare `;`, and archive refused because
+  the merged landscape "would not parse". The tag now takes the comma after it with it (or else
+  the comma before it), and takes a `;` when no tag is left in front of it. A tag after a comma no
+  longer leaves that comma behind either: `#x, #FEAT-1` lands as `#x`, where it used to land as
+  `#x,`.
+
+What the splice map still cannot locate is still refused (`merge-failed`, nothing written), and
+the message no longer guesses. It used to say "most often two declarations sharing one line"
+whatever the map held — over the reported declaration, which sat on a line of its own. It names the
+declaration (a relationship by its endpoints, where it used to give only a count) and the line
+LikeC4 parsed it on, then the cause the text shows: "it shares that line with '<other>'" only when
+other code precedes it on that line (its own kind keyword, or an edge's own source, is not other
+code); "the splice map read it as part of '<other>', which starts at line
+<n>" when the scan ran a statement on past a line break LikeC4 makes (a bare carriage return was
+the one such break until the splice map learnt to break there too, above); and otherwise that the
+splice map read nothing there, with the rewrite to make and a request to report the shape. Wording
+only; the code is unchanged.
+
+### Changed — `loam archive` refuses a delta that would bring back an operation another feature retired
+
+Two codes, both added to the `IssueCode` union, and one additive `--json` key were added.
+
+- **New `openapi.op-revived` (warn, gates archive).** A feature's `openapi.yaml` spells an
+  operation (by operationId) that its service's living contract no longer holds, and an ARCHIVED
+  feature retired it with an `x-loam-remove: true` marker — any archived feature, including one
+  whose directory carries the same feature id as the one being graded. Before this, the
+  quote read as an addition: a delta that had only quoted `createOrderV1` archived after the
+  feature retiring it and put it back into the living contract at exit 0, with the advisory
+  `api.op-unconsumed` the only finding. The message names the operation, the retiring feature(s)
+  and both remedies — delete the quote if it only restated the operation; archive with `--approve`
+  if the feature brings it back on purpose.
+- **New `asyncapi.slot-revived` (warn, gates archive)** — the same on the event axis: a `channels`
+  or `operations` slot by its key, or a message by its name, that an archived feature retired. A
+  channel-slot removal's inline messages are named from that feature's `.loam-before/` snapshot
+  pre-image, read only while it still hashes to the digest its manifest recorded.
+- **Both codes also cover an address an archived feature VACATED.** An archived feature that
+  relocated an operation (a marker on the old slot, the same operationId defined at a new one)
+  vacated the old address — and so did one that retired it there, once a later feature re-added it
+  somewhere else. A later delta quoting the operation at that address — unpinned — archived at
+  exit 0 and put the id back beside where it lives, one operationId at two slots (only the
+  advisory `openapi.duplicate-operationid` said so afterwards): the slot-keyed baseline gate saw
+  nothing living at the slot, and the id-keyed check saw the id living. That quote is now
+  `openapi.op-revived` too. Both codes are judged on the contract the archive would write: the
+  check runs the archive's own merge of the delta over the living contract and compares where each
+  operationId (each message name) stands there with where it stands now. One the merged contract
+  answers at two or more addresses — one of them new, and vacated by an archived feature — is the
+  finding; one the living contract still holds that it answers at exactly one address is not,
+  whether the delta moves it back with its own removal marker where it lives now or swaps another
+  operation in there (with or without an operationId — the merge replaces what stands at that
+  method and path). A removal marker standing where the id does not live deletes nothing, so it
+  no longer excuses the quote. The message says which archived feature moved the operation and
+  where to, or retired it there, and — apart from
+  that, since anything landed after can have moved it again — where it lives now; its remedy names
+  the address to drop: delete the quote, or, to move it back on purpose, add a removal marker
+  where it lives now — and where the delta already spells that address, so no marker can be
+  written there, archive with `--approve` instead. Where another operation lives at the quoted
+  address now (on the event axis, another message is declared at the quoted key), the message
+  names it and says archiving replaces it there — the merge writes one entry per address —
+  instead of calling the address one the living contract no longer has, and the move-back remedy
+  says to define it at another address (key) in the same delta if it is to stay: followed as it
+  read before, the remedy reached a clean gate and an archive that deleted the other operation
+  with nothing naming it. The retired-shape message names such an entry too. A quote of an
+  address an archived feature moved the operation away from is the finding even where the living
+  contract holds the operation nowhere (taken out of its new address by a hand edit, which leaves
+  no marker): the move is on the record, and the message reads as a retirement brought back,
+  naming the move. On the event axis the vacated addresses are `components.messages` keys (a
+  marker there) and the inline declarations a channel removal took; a delta that restates the
+  channel a name stands inline in with a `$ref`, or retires it, takes the name out of there and
+  is not graded. For an inline declaration the remedy names the channel (restate it with a
+  `$ref`, or retire it), never a marker nested on the inline message, which retires nothing. For
+  a `components.messages` key the remedy also names every channel (or operation) of the merged
+  contract still `$ref`-ing that key, to restate with the `$ref` pointed at the quoted key: told
+  only to retire the key, an author left the channel pointing at nothing, and its send stopped
+  sending the message — `asyncapi.remove-message-consumed`, which gates. `asyncapi.baseline-invalid`'s
+  move-back remedy says the same. A channel or operation slot is its key, so a "moved" one is a
+  retirement, as before. A message inline under a channel the delta brings back is reported by
+  the channel's finding alone only while the merged contract declares the name nowhere else; where
+  an archived feature re-declared it under `components` as it retired the channel, the inline
+  declaration is a finding of its own (one message name in two places) — it was skipped, and
+  `--approve` archived `asyncapi.duplicate-message`.
+- **Exit code: `loam archive` now exits 1 (`not-coherent`) on this shape** without `--approve`;
+  with `--approve` it merges as before, and the operation lands in `overridden[]` and the text
+  output's "archiving despite" list, naming what came back and whose retirement it reverses.
+  `loam validate --feature` and `--all` report both codes as warnings: exit unchanged, except
+  under `--strict`, which fails on any warning and so now exits 1 on this shape. `loam status`
+  counts them as gating like every warning that gates, and `loam show <FEAT> --json` reports
+  `review.readyToArchive: false` for such a feature until the quote is deleted (or the feature is
+  archived past it with `--approve`).
+- **`loam rebase` no longer calls a retired operation one "this feature is adding".** It pins
+  nothing for it either way, and now prints the same finding after its pin lines; the additive
+  `--json` key `revived[]` carries the findings (`severity`, `code`, `gates`, `subject`,
+  `message`). The operation's `pins[]` row still reads `unresolved`. The check runs over the
+  delta as rebase will write it, pins included, under `--dry-run` too: a quote pinned to its
+  own content is skipped by the merge, and repinned over another operation that now lives at an
+  address an archived feature moved it away from it becomes an edit that would put it back
+  there — that finding is in `revived[]` as well, and its `pins[]` row reads `repinned`. The
+  text output's revival banner no longer says "nothing was pinned" for such items.
+- **`openapi.baseline-invalid` and `asyncapi.baseline-invalid` reworded** for a pin whose living
+  operation or slot is gone: they used to say "drop the marker", which turned the quote into the
+  revival above. They now say to re-read the living contract and delete the quote unless the
+  feature deliberately brings it back. When the living contract still holds the operationId (or,
+  for a `components.messages` key, the message name) elsewhere, the message instead says a
+  parallel feature MOVED it there (or retired it here, and another re-added it there) and where it
+  lives now, and to make any change there — never to archive past the revival finding, which would
+  answer it at both addresses. The `/loam-check` rows and `loam explain` say the same. `loam
+  rebase`'s text says such items were retired by an archived feature "or moved to another address
+  by one".
+- **What it reads, and what it cannot see.** Only files under `features/archive/` — the archived
+  deltas' removal markers and each feature's `.loam-before/` snapshot; no git. A marker counts only
+  if the merge carried it out: the snapshot's pre-image must hold the marker's operationId at its
+  method and path (an event marker: its channel or operation key, or its message name at its
+  `components.messages` key), and a contract the archive created or never wrote lost nothing. A
+  marker archived past `openapi.remove-target-missing` / `-mismatch` (or the `asyncapi.*` twins)
+  under `--approve` deleted nothing, so a genuinely new operation it happened to name is not a
+  revival. A feature with no intact snapshot cannot be checked, and its markers count as written.
+  A removal made by hand-editing a living contract, or an archived feature deleted from disk,
+  leaves nothing to read, and a quote of such an operation still grades as an addition. A marker
+  with no `operationId` or one written at path level retired nothing when its feature archived, so
+  it is never named as the retirer.
+
+### Added — `#suite-<name>` tags and `loam list suites`: which services a test suite needs up
+
+No code was added. One reserved tag prefix, one list section and one positional argument were.
+
+- **A `dynamic view` may carry `#suite-<name>` tags** to say which test suites the journey runs in —
+  a separate prefix from `#cap-`, many-to-many (one view may carry several), each declared as
+  `tag suite-<name>` in the landscape's `specification` block like every LikeC4 tag, so a mistyped
+  suite is a parse error.
+- **A view carrying only `#suite-` tags is now a use case.** The one opt-in predicate takes three
+  prefixes (`cap-`, `req-`, `suite-`), and so does the byte scan that lets a fleet with no use cases
+  skip the LikeC4 load. Such a view's hops are graded by `loam validate` like any other use case's
+  (`usecase.step-unbacked`, `usecase.step-contested`, `usecase.step-unlinked` — at fleet scope, and
+  per service for a flow beside a service's model), and every reader that names use cases sees it:
+  `loam diff`'s removed-operation victims, `loam delta` and `loam status`'s use-case blast radius,
+  and the context packs. A view that already carried `#cap-` or `#req-` is unaffected, and an
+  untagged view is still never graded. On a fleet that had drawn `#suite-`-tagged views before this
+  release, those views can now earn findings.
+- **New section `loam list suites [<name>] [--json]`** — the answer to "which services must be up
+  for suite X". `[section]` accepts `suites`, and a new optional positional `[name]` narrows the
+  listing to one suite. Additive `--json` keys, emitted only with this section: `suites[]` (`name`,
+  `views[]` of `{id, file}`, `services[]` — enumerated service ids, sorted — and `unresolved[]` of
+  `{element, external}`: the participants that resolve to no service, `external` true when the
+  element or anything it is drawn inside carries `#external`, the walk stopping at the first
+  element bound to or titled for a service as `loam gate`'s partner reading does), `ungrouped[]` (`{id, file}` of every
+  use case carrying no `#suite-` tag, never narrowed by `[name]`), and `useCases` (`state`:
+  `absent` | `ok` | `unreadable`, beside `unreadable` and, when unreadable, `error`, spelled as
+  `loam list capabilities` spells them). Over an `architecture/` that does not parse the section
+  degrades instead of refusing, and `suites` / `ungrouped` are absent rather than `[]`. Only the
+  fleet map's use cases are listed. The text view prints one block per suite — its services, the
+  unresolved participants marked `!`, its use cases — then the use cases in no suite.
+- **Refusals use existing codes.** An unknown suite name is `unknown-target` with close names; a
+  `[name]` after any other section, and `--needs-work` with `suites`, are `invalid-option` (a name
+  after another section used to be commander's "too many arguments", also `invalid-option` under
+  `--json`). The campaign flags (`--subsystem`, `--owners`) refuse `suites` as they refuse every
+  section but `services`.
+- The MCP tool `loam_list` gains the matching optional `name` argument, and its `section`
+  description now lists `glossary` and `suites`. `name` without `section` is refused as invalid
+  params (`-32602`) rather than read as a section.
+- `examples/docs` tags its one use case `#suite-smoke` and `#suite-notifications`, so
+  `loam list suites` there answers checkout-web, notification-service and order-service, with
+  `customer` and the `#external` topic `kafka.orderEvents` named as unresolved.
+
+### Changed — the use-case byte scan opens on a `#` tag reference, not on a bare prefix
+
+No code, flag or payload key was added, changed or retired.
+
+- **loam starts LikeC4 for use cases only when a document references a reserved tag.** The scan in
+  front of every reader of the fleet's use cases, and of a service's own flows, used to open on the
+  bare text `cap-`, `req-` or `suite-` anywhere in a file. It now opens on `#cap-`, `#req-` or
+  `#suite-`, with only whitespace, line breaks or comments between the `#` and the name, as LikeC4
+  allows. That is the only way a view carries a tag, so no use case is missed.
+- **A broken `.likec4` beside a service's model that names a prefix only in prose no longer fails
+  the service.** In `0.2.0-alpha.8`, a file with no tagged view that mentioned `cap-` or `req-`
+  anywhere — a title, a comment — was loaded, and if it did not parse, `validate --service` (and
+  `--all`, per service) reported `usecase.flow-invalid`, an error, exit 1. This release's `suite-`
+  prefix would have added a third such substring (an id like `test-suite-runner`). Now the file is
+  skipped, like any untagged diagram.
+- **The same holds at fleet scope.** Suppose `architecture/` does not parse, carries no tagged view,
+  and only declares `tag cap-…` / `tag req-…` or names a prefix in prose. It now reads as declaring
+  no use case. `useCases.unreadable` is then `false` where it used to be `true` in
+  `loam status --json`, `loam delta --json` and `loam list capabilities --json`, and so is
+  `useCaseScan.unreadable` in `loam context --json`. `validate --all` still reports that map as
+  `landscape.invalid`.
+- A `#` followed by a reserved prefix still opens the scan wherever it is written, a comment
+  included.
+
+### Changed — `loam-feature` asks whether a feature is owed, and analyzes before it pins
+
+No code, flag or payload key was added, changed or retired. What changes is the protocol text an
+agent is handed, the `intent.md` a new feature starts from (and which of its text `intent.empty`
+counts), and what the documentation says a feature's contract delta holds.
+
+- **`loam instructions loam-feature` opens with a step 0.** A change that touches no requirement,
+  operation or fleet edge — a refactor, a dependency bump, a fix back to behaviour the living spec
+  already documents — needs no feature: a code PR, then `loam validate --service <id>` and
+  `loam vouch --pack --service <id>` in the service repo, and a person's vouch. WORKFLOW.md's "The
+  honestly-small change" now opens with the same lane.
+- **A new, ungraded step 4b, "Analyze before you pin", sits between authoring and `loam rebase`.**
+  The agent reads `loam show <FEAT> --json`, `loam context <service> --feature <FEAT> --json` and the
+  `explore` neighbours, then writes questions under `## Open questions` in `intent.md`: ambiguous
+  SHALLs, values, limits and windows two services state differently (and which side refuses),
+  `Realizes:` lines that do not deliver their capability, each edge's timeout, retry, partial
+  failure and compensation, and neighbours left out of `--touches`. A person answers by editing the
+  file. `loam-implement` sends an ambiguity it meets to the same section.
+- **`loam new` scaffolds an optional `## Open questions` heading in `intent.md`**, over a comment
+  only. **`intent.empty` now reads past that section:** questions an agent writes there are not the
+  feature's Why, so an intent whose only prose is open questions still gates the archive. The generated `loam-feature` command and skill pointers
+  list both new steps in their spine; an unedited pointer refreshes on the next `loam init`.
+- **A feature's `openapi.yaml` / `asyncapi.yaml` is documented as holding only what the feature
+  adds, changes or removes.** SCHEMA.md, WORKFLOW.md, the `loam-spine` and `loam-feature` pages,
+  the `spec.md` scaffold's comment and the example deltas taught "a complete document, not a
+  patch". The merge never needed one: it walks only the paths, methods and slots a delta spells, a
+  local `$ref` resolves into the living contract, and an add-only delta needs no `loam rebase`.
+  Each needless quote is one more pin and, once a parallel feature removes the quoted operation,
+  either a blocking `openapi.baseline-invalid` (pinned) or an archive that puts the retired operation
+  back (unpinned); `loam-check`'s fix for the first now says to delete the quote. The
+  `loam-spine` page also no longer says path-level keys and components go unpinned —
+  `x-loam-baselines` covers them.
+- **WORKFLOW.md gains "Build on the envelope":** a tracker export from `loam tasks <FEAT> --json`
+  keyed on unit ids (and what rewording re-keys one), a rollup of the per-service CI summaries
+  that reads a missing or old report as unknown, and `npx likec4 mcp` beside `loam mcp` on the same
+  docs repo.
+- **The `loam-codes` page points at AGENTS.md's "Reference pages — fetch when needed" section** —
+  it named a "The reference pages" section that does not exist — and lists `loam-report` among the
+  pages `loam instructions` prints.
+
+### Added — `loam new --modifies <Req-ID>`: a small change is new → edit → archive
+
+- **New repeatable flag `--modifies <Req-ID>` on `loam new`.** Each value names a living
+  requirement, by its `Requirement-ID:`, in a service the feature `--touches`. The scaffold copies
+  that requirement into the service's delta, uncommented, under `## MODIFIED Requirements`, with
+  its `Based-On:` pin already set. It is the same pin `loam rebase` writes, so a rebase right after
+  reports it `unchanged`, and the living text moving before archive is still `delta.baseline-stale`.
+  An `arch.spec.md` requirement lands in a scaffolded `specs/<svc>/arch.spec.md`. Before this, the
+  author copied the requirement by hand and ran `loam rebase` to pin it.
+- **When every touched service has a `--modifies` and no `--new-service` or `--capability` is
+  given, no `delta.likec4` is written.** A feature that only rewrites requirements changes no
+  architecture, and the scaffold already told authors to delete the file in that case. `created`
+  in `--json` simply omits it. Any other combination scaffolds `delta.likec4` as before.
+- **Refusals use existing codes.** An id that no touched service's living spec carries is
+  `unknown-target`. The message names the close ids in those specs, or the untouched service that
+  does carry the id (`add --touches <svc>`). A value that is not a Requirement-ID, or an id two
+  touched documents both carry, is `invalid-option`. A living spec loam cannot decode is
+  `merge-failed`, as `loam rebase` refuses it. Every refusal writes nothing.
+- The opt-in MCP author tool `loam_new` gains the matching `modifies` argument. No code or payload
+  key was added.
+
+### Added — `loam_adopt`: the adopt brief on the MCP server
+
+- **`loam mcp` serves a sixteenth read tool, `loam_adopt`**, mirroring `loam adopt [--service <id>]
+  [--subsystem <name>] [--targets] --json` (JSON arguments `service`, `subsystem`, `targets`). Its
+  result is the CLI's `adopt` envelope, verbatim. It is advertised `readOnlyHint: true` like every
+  base tool, because `adopt` writes nothing: it hands the agent the brief, and the agent writes the
+  baseline. Until now an MCP-only host could fetch the loam-adopt protocol through
+  `loam_instructions` and could not run its first step, `loam adopt --service <id> --json`. No
+  code, flag or payload key was added to the CLI; `tools/list` returns one more tool.
+
+### Changed — `loam init --create` with no service prints the docs repo's first hour
+
+- **A run that creates a docs repo and binds no service now ends with `next — the docs repo's first
+  hour:`**: `loam seed --from fleet.yaml` (or draw the map by hand), `loam init --docs <docs-repo>
+  --service <id> --agent-profile service` in each service's own repo, `loam adopt --service <id>
+  --json` there, and `loam status`. It used to print nothing after the scaffold list. These are
+  WORKFLOW.md's Day zero steps and the rungs `loam status` already names on an empty fleet. A run
+  that binds a service still prints the single-repo trial's hour, and a join still prints neither.
+  Human output only: no code, flag or payload key was added, and the `--json` envelope is unchanged
+  for both variants.
+
+### Changed — every service bind loam prints names `--agent-profile service`
+
+No code, flag or payload key was added, changed or retired. What changes is printed text and one
+`--json` value.
+
+- **The bind command now reads `loam init --docs <path> --service <id> --agent-profile service`**
+  in `loam status`'s `next.bind-service` step, its `loam explain` entry, the docs repo's first hour,
+  the generated AGENTS.md (`## The cycle`, step 0), and the `loam-adopt` and `loam-implement`
+  protocols. README, QUICKSTART and docs/SERVICE-TEAMS.md already told a fleet to bind each service
+  checkout this way, because `--agent-profile` defaults to `full`, and `full` writes `loam-feature`
+  and `loam-ship` into the service repo. But every bind command loam printed left the flag out, and
+  an agent runs the command loam prints. WORKFLOW.md's Day zero step 3 now spells it too.
+- **`next.bind-service`'s `command` in `status --json` `next[]` carries the new text.** Its
+  `execution` block still names the same two placeholders.
+- **Two binds keep their old form on purpose.**
+  - `loam-adopt` names the single-repo trial (`--create`, used only when the docs repo does not
+    exist yet) as the one bind that keeps the full profile.
+  - `doctor.service-unbound`'s fix is a re-run in a checkout that is already wired. An omitted
+    `--agent-profile` there keeps the profile that checkout recorded.
+
+### Changed — the OpenSpec compatibility pin moves to v1.14.1, and a weekly canary watches the newest release
+
+No code, CLI flag or payload key was added, changed or retired. The `audit-openspec` /
+`migrate-openspec` payload shape is unchanged, but the value it reports as the certified release moves.
+
+- **`audit-openspec` and `migrate-openspec` now report OpenSpec v1.14.1 as the certified release.**
+  The banner line and `baselines.release` under `--json` carry `1.14.1` / `v1.14.1` /
+  `87c3595ace6a2e22957f39ebe5b74c2f2316e0cb` (released 2026-10-05) instead of `1.9.0` / `2826b88`.
+  `baselines.mainCanary` is unchanged. The corpus gate's `--baseline release` is now the v1.14.1
+  corpus: 223 Markdown files, 765 requirements and 2475 scenarios, every file round-tripped. v1.9.0
+  stays as the new `--baseline previous` regression pin beside `legacy` (v1.7.0) and `canary`, and
+  the scheduled `ci.yml` matrix runs all four. The sweep found no parser gap. The grammar OpenSpec
+  1.13 added — a closing `#` run, `*`/`+` bullets on `REMOVED` and `RENAMED`, repeated delta
+  sections — was already read by the migration, and a new test pins the repeated sections.
+  `audit-openspec` and `migrate-openspec --apply`, run on OpenSpec's own v1.14.1 workspace, staged
+  all 251 living requirements and 747 scenarios across 36 services. The seven vendored fixtures stay
+  at v1.9.0, since v1.14.1 has no shape they lack. MIGRATING-from-OpenSpec.md's version matrix
+  records all of this.
+- **The corpus sweep reads each file through the migration's own reader.** That reader is the one
+  `audit-openspec` and `--apply` use: loam's parser plus the grammar only OpenSpec accepts. The
+  sweep used to read with loam's parser alone. Every pinned corpus gives the same totals either way.
+- **A new scheduled workflow, `.github/workflows/openspec-canary.yml`, watches the newest OpenSpec
+  release.** It runs weekly and on manual dispatch. It resolves the newest `vX.Y.Z` tag with
+  `git ls-remote` and sweeps it with the new `--baseline latest` mode of `npm run
+  test:openspec-corpus`. That mode reports how the totals moved from the certified pin instead of
+  refusing an unpinned commit, and still fails on a file that does not round-trip. The workflow also
+  audits OpenSpec's own workspace and diffs upstream's parser sources against the pin, in its step
+  summary. It has no push or pull-request trigger and blocks nothing; CONTRIBUTING.md's "The
+  OpenSpec canary" is the runbook. The README's note that `--baseline` defaults to `canary` was
+  wrong — it defaults to `release` — and now says so.
+
+### Added — documentation: running loam where service work runs, a CLI-only first ten minutes, and what loam costs an agent
+
+No code, flag, command or payload key was added, changed or retired; the binary is unchanged. The
+new paths are `docs/SERVICE-TEAMS.md` and `scripts/payload-sizes.ts`.
+
+- **README has a service-repo CI recipe** beside the docs repo's fleet-edges one. The workflow
+  checks out the service and the docs repo as sibling subdirectories of the workspace, so a
+  committed relative `docsDir` such as `../docs` resolves. It does not use `path: ../docs`, which
+  `actions/checkout` refuses. It runs `loam validate --service <id> --json` at the same pinned
+  version, and two `jq` programs turn the findings, or a refusal, into `::error` / `::warning`
+  annotations and a `$GITHUB_STEP_SUMMARY` table. A deploy pipeline can add
+  `loam gate --service <id> --since <ref>`. It is followed by setup for cloud agents in a service
+  repo: a `copilot-setup-steps.yml` and a Codex environment setup script, each cloning the docs
+  repo into the committed `docsDir` with a read token from a secret.
+- **README's day-zero binding passes `--agent-profile service`**, and says why: the profile
+  defaults to `full`, which puts `loam-feature` and `loam-ship` into every service checkout.
+  QUICKSTART's command for joining a shared docs repo passes it too.
+- **QUICKSTART opens with ten minutes of CLI only.** A two-service `fleet.yaml`, `loam seed`, one
+  provider `openapi.yaml` and one misspelled `op` on an edge give `spine.op-undefined`, with no
+  agent and no adoption. A requirements-only `loam new --touches … --touches …` then validates and
+  plans its archive before either service is adopted. Every output shown was produced by running
+  the commands. The single-project path moves to sections 3–6.
+- **`docs/SERVICE-TEAMS.md`, one screen for a team whose repository is one service in a fleet:**
+  four commands, five slash commands, what a person signs when they vouch, and the fifteen codes
+  they will actually meet. README, QUICKSTART and the Docs list link to it.
+- **COMPARISON.md names OpenSpec, Spec Kit and Kiro again, in one dated section.** "Spec-driven
+  change tools, as of October 2026" sets out what each offers for a change that crosses
+  repositories: OpenSpec Stores and worksets, `show --diff` and the Cloud Agent; Spec Kit's
+  contract-driven guide, `/speckit.converge` and MCP server; Kiro's Design-First specs and Kiro
+  Web. It records what is still open upstream (OpenSpec #725, Spec Kit #4583) and where loam
+  differs, including the two gaps it has against them. Each claim links its source. The rest of
+  the page stays an ecosystem map, and `test/docs-drift.test.ts` now allows the three names only
+  inside that dated section.
+- **`docs/BENCHMARKS.md` has a table of agent-facing payload sizes**, in bytes and ~tokens:
+  the generated `AGENTS.md`, `loam adopt --service <id> --json` with and without `--targets`,
+  every `loam instructions` page with and without `--no-fix-tables`, and `loam explain <code>
+  --json` across the whole vocabulary. `npx tsx scripts/payload-sizes.ts --write` generates it from
+  the tree, and `test/docs-facts.test.ts` regenerates it and fails when the committed table
+  differs. README's adopt row now points at that table instead of quoting a dated figure.
+  `test/docs-drift.test.ts` now also requires every exact `@ybotok/loam@<version>` in README to be
+  this checkout's version.
+
+### Changed — `loam archive`'s overwrite warnings name the current consumers
+
+No code or flag was added. Existing warnings now fill a payload key that was always empty.
+
+- **`openapi.op-modified` and `asyncapi.message-modified` now say who the overwrite affects.**
+  Each message ends with one of three phrases: `N current consumer(s) still name it`,
+  `whether current consumers name it could not be fully answered`, or
+  `no current consumer names it`. The warning's `details` (until now always `[]`) list the
+  consumers, in `archive --json` `warnings[]` and, when the contract merge is refused as
+  `not-coherent`, in the same warning's entry in `issues[]`:
+  - edges of the `architecture/` project;
+  - other services' living requirements, in either spec file;
+  - use-case hops;
+  - and last, any consumer whose documents could not be read, or any caller drawn without an
+    `op`.
+
+  The human plan prints the same lines under the warning. This is the scan `loam diff` runs for
+  `diff.op-modified` and `diff.message-modified`. Here it runs over the living fleet as it stands
+  before the merge, and only when one of these warnings fires. On the 120-service benchmark fleet
+  that costs about 130 ms. Severity is unchanged, and neither warning gates the archive. Whether a
+  change breaks a consumer is still not graded (`oasdiff breaking` / `asyncapi diff` do that).
+- `openapi.component-modified` and `asyncapi.component-modified` do not name consumers. A
+  component's consumers are the operations or messages whose `$ref` closure reaches it, and loam
+  has no index of those.
+
+### Fixed — an MCP tool argument is never read in another argument's slot
+
+No code, flag or payload key was added, changed or retired. Two MCP input schemas each gained one
+JSON Schema keyword, named below.
+
+- **A `tools/call` that supplies an optional positional argument while leaving out an earlier one is
+  refused as invalid params (`-32602`)**, naming the argument left out, as a missing required
+  argument already is. Positionals reach the command by position, so the later value used to be read
+  as the earlier one: `loam_instructions` with `args` and no `workflow` took the first arg as the
+  workflow name. An empty `args` still passes. The defect is present in `0.2.0-alpha.8`.
+- **The MCP tools' advertised input schemas now say that `name` needs `section` and a non-empty
+  `args` needs `workflow`**, the rule a tool call already enforces, so a client that validates a
+  call against `tools/list` is no longer refused `-32602` for a call the schema allowed.
+  `loam_list`'s schema gains `dependentRequired` (`name` → `section`); `loam_instructions`' gains
+  `dependentSchemas`, requiring `workflow` once `args` has a member, because an empty `args` still
+  passes. Both are standard JSON Schema keywords; no tool, argument or other schema key changed.
+
+### Fixed — `loam validate` reports an unreadable verification record from the docs repo
+
+No code, flag or payload key was added. An existing code fires in one more place.
+
+- **`evidence.record-unreadable` (warn) now fires on the feature target too**, under
+  `validate --feature <FEAT>`, `validate <FEAT>` and every active feature under `validate --all`, run
+  from anywhere. A `features/<FEAT>/verification.yaml` or `verification/<svc>.yaml` with git
+  conflict markers, broken YAML, a shape that is not a record, or a summary that contradicts its
+  claims used to pass `validate --all` in the docs repo with no finding. `verify` refused the file,
+  and `status`, `gate` and `tasks` reported it. Until now only the service target raised this code,
+  and only from the service's own repository. The finding names the file and gives the same repair
+  as the service-target finding. Its `locations` hold that file as `primary`. It is a warning, as
+  it is on the service target. `valid`, the exit code and `loam archive` are unchanged, and
+  `--strict` fails on it. In a service repository's `validate --all` the same file is reported
+  twice: once by the service target and once by the feature target.
+
+### Fixed — `loam diff` reads a spec saved as UTF-16 without a byte-order mark the same way on both sides
+
+No code, flag, path or payload key was added, changed or retired.
+
+- On disk, a `spec.md` or `arch.spec.md` saved as UTF-16 without a byte-order mark was refused as
+  unreadable. At the base ref, the same bytes were read as a readable spec with no requirements.
+  That happened because only the working-tree side checked for NUL characters. So an untouched file
+  was suspended on one side only, and a branch that re-saved the file as UTF-8 reported every
+  requirement in it as `diff.requirement-added`. The base side now applies the same decoding rule as
+  the working tree. Both sides report the file as unreadable, and the spec axis is suspended. The
+  contract axes are unchanged: their readers on both sides already applied the same rule.
+
+### Fixed — a writer waiting on the lock no longer deletes the next writer's live lock
+
+No code, flag, path or payload key was added, changed or retired. What changes is that concurrent
+writers no longer fail, or share one commit window, when a lock holder exits while another writer
+waits for it.
+
+- **A stale `.loam-lock` is broken only while the holder judged dead still holds it.** A writer
+  that finds the lock held reads the holder, and if that pid no longer exists on this host, it
+  breaks the lock. Under CPU load the holder could release normally and exit between that read and
+  the pid check, and a third writer could take the lock in the same gap. The waiter then deleted
+  the third writer's live lock and took one of its own, so two writers were inside one commit window.
+  One of four concurrent `loam gherkin --json` runs failed as `merge-failed` (`ENOENT … rename
+  '….feature.loam-<pid>-…tmp'`): the second writer's recovery read the first's in-flight journal as
+  an interrupted commit and swept its staged files. The code is shared by every writer that takes
+  the lock (`archive`, `unarchive`, `new`, `seed`, `rebase`, `subsystem`, `verify --record`, `vouch`,
+  `gherkin`), and the defect is present in `0.2.0-alpha.8`. The waiter now re-reads the lock after
+  its verdict, and moves it to a private name before removing it. Anything it moved that is not the
+  lock it judged goes back in place. A crashed holder's lock is still reclaimed as before.
+
+### Fixed — `validate --all --base` grades the landscape by what the branch changed in it
+
+No code, flag, path or payload key was added, changed or retired; the unscoped `validate --all` is
+unchanged.
+
+- **A call edge the branch adds or edits in `architecture/` is graded against its provider's
+  contract**, even when the provider is not in scope. README's own example — `authorisePayment` on
+  an edge into a contract spelling it `authorizePayment` — used to pass both PR gates on the example
+  fleet and, even under `--strict`, on a freshly seeded spine-first fleet. It now fails as
+  `spine.op-undefined` (and `spine.op-deprecated`, `spine.op-link-missing` and `spine.resolved` read
+  the same way), filed on the `landscape` target. Only those edges are graded: the provider is not
+  pulled into scope, so its own documents — on a seeded fleet, its `service.no-model` — stay out of
+  the PR's verdict. An edge is new when its (source, target, op) is; a reformat grades nothing.
+- **An edge whose metadata or tags hold a word containing `op` is graded on the op it names.**
+  `--base` finds the branch's edges by reading the map's text, and that reading took
+  `op-version 'v2'` above `op 'cancelOrdr'` for op `v2`, and a `#op-critical` tag for an op naming
+  the description below it. The edge it read matched no edge in the parsed map, so the branch's
+  misspelt `cancelOrdr` was graded nowhere: exit 0 and `valid: true`, where the unscoped run
+  reports `spine.op-undefined`. A key is read whole now, and the op only from `metadata { }`.
+- **An edge written after a bare carriage return is graded on its own source.** After a `link`,
+  `description` or `technology` property ending in a bare `\r`, the parent's sourceless
+  `-> target` edge was read as an edge FROM `link` (or `description`, or `technology`), and an edge
+  after a `// comment` ending in a bare `\r` was not read at all. Either way the branch's op on that
+  edge was graded nowhere, with the same exit 0. LikeC4 breaks a line at a bare `\r`, and the
+  reading does too now.
+- **The landscape re-grades a fleet-wide vocabulary only when the file that carries it changed.**
+  `permissions.*` rides a scoped run only when `architecture/permissions.yaml` changed,
+  `capability.*` only when `architecture/capabilities.yaml` or `capabilities/` did,
+  `obligation.invalid` and `obligation.unapplied` only when `architecture/obligations.yaml` did,
+  `glossary.*` only when `glossary/` did, and `agents.stale` / `docs.binary-behind` only when
+  `AGENTS.md` did. A one-line map edit on the example fleet is no longer red under `--strict` on four
+  warnings that were all there at the base.
+- README's spine-first section now says that under the `--base` gate a PR adding a service's
+  `openapi.yaml` stays red until that service has a `model.likec4` — `service.no-model` is the
+  ratchet working as designed.
+- **Each service target in scope reports a committed map that does not parse, even when the branch
+  left `architecture/` alone.** On such a branch the scoped run emits no `landscape` target, yet
+  each service in scope still said `spine.landscape-invalid … the parser output is reported once,
+  on the landscape target`, with empty `details`. So the parser output was reported nowhere. Each
+  service's `spine.landscape-invalid` now carries the parser output in `details` whenever the run
+  has no `landscape` target, as `validate --service` always has. A feature target does not report
+  the map, so a run whose only targets are features still says nothing about it. The defect
+  predates this release's `--base` changes and is present in `0.2.0-alpha.8`.
+
+### Fixed — one LikeC4 typo no longer floods agent-facing output
+
+No code, flag, path or payload key was added, changed or removed; what moves is the TEXT of the
+diagnostics LikeC4 hands loam, and one warning that stops cascading.
+
+- **A parser's "Expecting: one of these possible Token sequences" message is cut to its first four
+  alternatives plus `… (+N more)`**, keeping the `but found: '…'` line — on every surface that
+  prints a LikeC4 diagnostic (`validate`, `context`, `show`, `tasks`, `doctor`, `gate`,
+  `archive`). One dropped quote in the example fleet's order-service model made `loam validate
+  --service order-service` print 18,503 lines (434 KB; 458 KB as `--json`); it now prints 27 lines
+  (1.7 KB; 5.5 KB as `--json`).
+- **Each LikeC4 diagnostic is reported once, in line order.** The same message at the same line of
+  the same file used to be listed twice, and the lexer's error led the parser's even when it sat a
+  dozen lines below the fault. The `N error(s)` count in `c4.invalid`, `delta.invalid` and the other
+  parse findings now counts distinct diagnostics.
+- **`covers.unknown` is no longer raised for a service whose own `model.likec4` does not parse.**
+  `c4.invalid` is the one finding; the six `covers.unknown` warnings the example fleet showed for one
+  dropped quote named ids that were spelled right. The same suspension already applied to a model
+  extending a map that does not parse.
+- **A broken document no longer bloats anybody else's briefing.** A dropped quote in a feature's
+  `delta.likec4` made `loam context order-service --json` 626 KB instead of 24 KB (now 27 KB). The
+  fleet map's parse error reached `useCaseScan.error` on every service's `context --json` and the
+  `loam gate` "landscape cannot be used" message raw — 173 KB and 152 KB — and now goes through the
+  same spelling as every other diagnostic, which adds its 1-based `L<n>:` line (23 KB and 2 KB).
+
+### Fixed — `doctor.agent-files-stale` fires on a changed body, not on every release
+
+No code, flag, path or payload key was added, changed or retired; what a repo NOTICES is that
+`loam doctor` stops warning about generated command and skill files whose only difference is the
+version stamp.
+
+- The stamp sits inside every generated command and skill file, so every release used to turn every
+  one of them stale in every repo, even when the release had not changed a word of the pointer — a
+  warning that is always on, which then hid the release where a pointer really did change. A file is
+  now stale only when its body, the stamp line set aside, is not what this loam writes, AND its stamp
+  is missing or older. Line endings do not count (a Windows checkout that converts them to CRLF is
+  not a change). A customized body under a current stamp stays quiet, as before. Same code, same severity;
+  the `agents.staleFiles` list in `loam doctor --json` simply stops naming stamp-only files.
+
+### Fixed — relationship order is the same on every run
+
+No code, flag, path or payload key was added, changed or retired; lists built from relationships
+come back in one stable order.
+
+- LikeC4 indexes relationships by a hash of the document's path, and loam stages documents under a
+  fresh random folder per run, so an edge whose hash happened to come out all digits (about one in
+  2,200) jumped to the front of the list on that run only; inside a project of several documents the
+  base order was whichever file finished reading first. A scheduled CI run failed on it. Every loader
+  now returns relationships sorted by source, target, title, `op`, `publishes`, `consumes` and tags,
+  so anything listed from edges — `loam explore`'s neighbours, the candidates a
+  `usecase.step-contested` finding names, findings emitted per edge — keeps one order between runs
+  and machines. That order is no longer the declaration order.
+
+### Fixed — the repository no longer claims a version is published
+
+No code, flag, path or payload key was added, changed or retired; only documentation moved.
+
+- README called the version in `package.json` "the newest published version", by construction of
+  the test that pinned it — and kept saying so for `0.2.0-alpha.8`, whose publish failed. It now
+  names that version as the version of the checkout and points at the npm dist-tags as the source of
+  truth; the drift test forbids the publication claim in README and in the CHANGELOG section of the
+  checkout's own version. The `0.2.0-alpha.8` section below carries a dated note that it was never
+  published.
+- The `0.2.0-alpha.3` section promised that installing `@ybotok/loam@alpha` gets it. That release was tagged
+  and withdrawn before its publish step, which only the `0.2.0-alpha.4` section said. It now carries
+  the same kind of dated note.
+- README said Codex reads `.codex/skills/`. That is the folder the `codex` target writes, and Codex
+  still loads it, but Codex's skills documentation names only `.agents/skills`. README now says so
+  and points at the `agents` target for the documented root. The `codex` target's path is
+  unchanged.
+- README and WORKFLOW no longer quote byte sizes and code counts that had gone stale (the
+  `loam-check` page, the AGENTS.md orientation, the finding-code total). A finding- or refusal-code
+  count quoted on a shipped page is now graded against `loam explain --codes`.
+
+### Changed — `loam archive` moves the delta's bytes and nothing else's
+
+- **The requirements merge splices instead of re-serializing.** A living requirement the delta does
+  not touch is written back byte for byte; only ADDED requirements and the ones a MODIFIED replaces
+  are serialized. Before, the whole `## Requirements` run was re-serialized, so a living spec
+  written without a blank line under `### Requirement:` had one inserted under every untouched
+  requirement by its first archive — the diff, `loam vouch --pack` and the re-vouch all widened to
+  the whole section. `loam unarchive` is unchanged and still restores every byte. Each kept slice
+  is matched to its requirement by `Requirement-ID:` (the heading when there is none), never by
+  position; if the slices and the living requirements do not match one to one, the whole run is
+  re-serialized as before rather than one requirement's text landing in another's place.
+- **`archive --json` gains the additive `revouchOwed` key** (`[{service, path, owner}]`, on the
+  dry run and the real merge alike): every vouched living `spec.md` / `arch.spec.md` the merge
+  moves under its vouch stamp, with the frontmatter's `owner` (`null` when none is recorded).
+  `content.stale` follows on each — unchanged and still a warning; no new code, nothing `--strict`
+  lets through. The human view prints the same list under a `re-vouch owed` line, naming
+  `loam vouch --service <id>` and saying the re-vouches belong in the archive's own PR, which
+  `loam validate --all --base <ref> --strict` keeps red until they land. The `/loam-ship` protocol
+  gains that step, and README's docs-repo PR recipe says so.
+- The human view of `loam archive` no longer prints its `archive <id>` header twice.
+
+### Fixed — the adopt brief's spec examples
+
+- The `spec.md` and `arch.spec.md` examples in `loam adopt`'s brief name the service being adopted
+  in their frontmatter `service:` and title, where they used to say `payment-service` for every
+  service — a verbatim paste failed `frontmatter.field-mismatch`. Their requirements now carry the
+  canonical blank line under `### Requirement:`, so a spec copied from them is not reflowed by its
+  first archive.
+
+### Fixed — fleet readouts tell the truth about trust
+
+A vouched spec edited after the vouch (`content.stale`, computable from the docs repo) was reported
+by `loam validate` and by no fleet readout; `sources.unwalked` fired in every service repo straight
+after a fresh vouch; and the human `status`/`list` views printed a verification count without
+saying who answered it. Additive throughout — no code, flag or key changed or was removed, and the
+maturity rung of every service is unchanged.
+
+- **New stable code `next.revouch`** in `loam status`'s fleet `next[]` (and under `--service`): one
+  step per vouched service whose `spec.md` or `arch.spec.md` changed since the vouch, naming the
+  documents. Its `command` is `loam vouch --service <id>` and its `execution` is
+  `kind: "human-review"`, `runnable: false`, `cwd: "service-repo"` — a re-vouch is a person's act.
+  While one stands, `status` no longer reports `next.fleet-clean`.
+- **New payload key `services.contentStale`** on `loam status --json` (fleet form): of `vouched`, the
+  services with a document moved under its stamp — a subset, like `sampledVouched`. The human line
+  reads `N vouched (M stale)`.
+- **New payload key `scorecard.provenance.contentStale`** on `loam validate --all --json`: services
+  with a `content.stale` finding in that run. The text row reads `N vouched — M stale content ·
+  K stale digest(s) · …` (it used to say `0 stale digest(s)` beside the warning).
+- **New payload key `answered` inside `verification`** on `loam status --json` (the feature form, and each
+  `features[].verification` of the fleet form) and on each `features[]` row of `loam gate --json`,
+  which spreads the same record: the confirmed claims per `answered_by`
+  (`runner`, `external-runner`, `agent`), the split `list --json` already carried. The human views
+  print it beside the verdict — `status <FEAT>` as `verified 19/19 confirmed (13 runner · 6 agent)`,
+  `list`'s verification column as `7/7 (5 runner · 2 agent)`. The verdict and its definition are
+  unchanged.
+- **`loam list`** shows such a service as `vouched (stale)` (or `vouched (sampled, stale)`) and counts
+  it in the maturity line; its `missing` — in text and in `--json`, and likewise in `explore` and the
+  context pack, which share it — now reads `re-vouch (<file> changed since the vouch)`, so
+  `list --needs-work` (with `--review-order` and `--owners`) lists it instead of answering
+  "nothing to do". The `maturity` value stays `vouched`.
+- **`sources.unwalked`** no longer counts loam's own files — `loam.json` and the agent files recorded
+  in its `agentFiles` — or any `.gitignore` toward its denominator. `.gitignore` is the file that
+  defines what git tracks, so it is the measuring instrument, never a part of the service a spec
+  owes; `package.json`, READMEs and the like stay in. A freshly vouched service repo is no longer
+  red under `validate --service --strict` for files it cannot honestly list in `sources`.
+- **`loam list` legend** names the `e` (events / AsyncAPI) column: `[e]vents`.
+- **SCHEMA.md**: the per-service CI summary shape gains `contentStale` (the count of `content.stale`
+  findings), and its jq derivation counts it. **WORKFLOW.md** states that `loam gate --strict` also
+  fails on a join partner's `content.stale`.
+
+### Added
+
+- **New warning `frontmatter.owner-mismatch`** from `loam validate` (`--service` and `--all`) when
+  one service's `spec.md` and `arch.spec.md` both name an `owner` and the two differ. `loam show`
+  and `loam context` print only `spec.md`'s owner, so the other value was a second answer nobody
+  saw. Its `details` list each file's value (`spec.md: <owner>`, `arch.spec.md: <owner>`). Silent
+  when either file names no owner (that stays `frontmatter.field-missing`). It compares the two
+  files only, never CODEOWNERS. As a warning it fails `loam validate --strict`, so a service that
+  passed `--strict` with two different owners now exits 1 there until they agree.
+- **`openapi.generated-stale` now says what moved.** The finding gains `details` naming each
+  operationId that differs between the build's contract and the committed copy — `served, not in
+  the committed copy: <id>` and `committed, no longer served: <id>` — and its message counts both
+  sides, or says every operationId matches when the difference is inside an operation or outside
+  `paths`. The digest still decides whether it fires; same code, same severity.
+- **`diff.op-modified` (warn)**: an operationId present at the base ref and now, whose operation
+  changed — its own definition, its method or path, or anything its internal `$ref`s reach, so a
+  field renamed in a shared `components` schema counts. **`diff.message-modified` (warn)** is the
+  same for an AsyncAPI message: its declaration or anything its payload `$ref`s reach. Both name
+  the authored consumers in `details[]` (the same scan `diff.op-deprecated` runs) and point at
+  oasdiff or `asyncapi diff`; neither grades whether the change is breaking, so neither sets
+  `breaking` or changes the exit code. A PR that renamed a required field used to print "no
+  fleet-meaningful changes" and exit 0 with nothing else.
+- **The `modified` count in `loam diff --json`'s `summary` now counts both new codes** beside
+  `diff.requirement-modified`. The key is unchanged; a diff over a changed contract reports a
+  higher number than before.
+- A newly deprecated operation is still reported once, as `diff.op-deprecated`, not also as
+  `diff.op-modified`.
+
+### Changed
+
+- **An AsyncAPI 1.x or 2.x document is `asyncapi.invalid`, once.** loam reads AsyncAPI 3.0 only,
+  and a document whose `asyncapi:` field says `1.` or `2.` used to read as a 3.0 contract with no
+  messages: one `spine.message-undefined` per landscape edge, one `spec-event.message-undefined` per
+  requirement and a `spine.message-unproduced` on every consumer, none naming the version. It now
+  takes the unreadable path every broken contract takes — one `asyncapi.invalid` whose `details`
+  name the version and `asyncapi convert --target-version=3.0.0`, and nothing on the event axis
+  graded against it. The same applies to a feature's own `asyncapi.yaml` under `--feature`. The
+  `asyncapi.invalid` message, and the `context` / `delta` lines for an unreadable event contract,
+  now say "does not read as AsyncAPI 3.0" rather than "does not parse". **It is an error:
+  `loam validate` now exits 1 on such a document even where no edge or requirement names its
+  messages** — a document that used to pass. `asyncapi convert --target-version=3.0.0` upgrades it.
+- **`loam diff --base <ref>` exits 1 while a CHANGED `asyncapi.yaml` says 1.x or 2.x.** The
+  document is listed in that service's `unreadable[]` once for each side on which it says 1.x or
+  2.x, counted in the `unreadable` total of `summary`, and the service reads
+  `change: "changed"`; it used to read as a contract with no messages and exit 0. One the branch
+  did not touch does not do this — see the next entry. `asyncapi convert --target-version=3.0.0`
+  upgrades it.
+- **`loam diff --base <ref>` skips an unreadable `openapi.yaml` or `asyncapi.yaml` that the base
+  ref holds byte for byte.** Such a contract is no longer listed in `unreadable[]`, counted in
+  `summary`, or the reason a service reads `change: "changed"`, so an unconverted
+  AsyncAPI 2.x file, or a broken OpenAPI file, that the branch never touched no longer fails every
+  PR's diff with exit 1. A contract the branch changed, or one only one side cannot read, still
+  suspends its axis and exits 1. `spec.md` and `arch.spec.md` are not skipped: an unreadable one
+  stays suspended even when untouched, because another service's removal may be the one that
+  could not be checked against it. No key is added or removed.
+- **Suggested element ids follow `loam seed`'s convention.** For a service the fleet map does not
+  draw yet, the `loam adopt` brief and the `loam new` delta scaffold now suggest `svc_<id>` (dots
+  and dashes folded to `_`, e.g. `svc_payment_service`) instead of a camel-cased name, and
+  `loam new --touches <id>` reuses the element id the map already draws the service as. A service
+  the map nests inside another element is quoted by its last segment with a note naming the parent,
+  since a dotted id is no top-level declaration. The commented example in a freshly seeded
+  `architecture/landscape.likec4` uses the seeded ids too. Element ids stay cosmetic —
+  `metadata { service '<id>' }` is the join — so nothing already written needs to change.
+- **`seed-landscape-edited` gives advice that can be followed.** The refusal and `loam explain
+  seed-landscape-edited` used to say "fold the edits into fleet.yaml and delete the file", which is
+  impossible once an edge carries `metadata { op }` (fleet.yaml cannot). They now say seed runs
+  once, before any operation is drawn, and that the map grows from then on through
+  `loam adopt --service <id>` and feature C4 deltas. Same code, same exit code.
+- **`migrate-openspec` and `audit-openspec` read the OpenSpec 1.13 requirement grammar.** A
+  `RENAMED` pair written with a `*` or `+` bullet, or with no bullet, is a pair (it was
+  `openspec.renamed-malformed`); a `REMOVED` section written as a bullet list (`-`, `*` or `+`) of
+  requirement headings is read as those removals (it was `openspec.change-empty`); and a closing
+  `#` run on a `### Requirement:` or `#### Scenario:` heading is dropped at ingest, so
+  `### Requirement: Invoice totals ###` stages as `Invoice totals` and a MODIFIED delta naming it
+  no longer fails `loam validate` as `delta.modified-unknown`. loam's own parser is unchanged.
+- **An inbound landscape edge into the provider with no `metadata { op }`** (and no
+  `publishes`/`consumes`) is now listed in the `details[]` of `diff.op-removed`,
+  `diff.op-removed-consumed`, `diff.op-deprecated` and `diff.op-modified` as a consumer whose
+  operation is unknown. A removal with such a caller and no named one now says "could NOT be fully
+  answered" instead of "no current landscape edge or living requirement names it". It stays a
+  warning, exit 0: a map `loam seed` drew, every edge without an op, does not fail every removal.
+- **Without `--json`, a commander usage error** (a missing `--base` on `loam diff`, an unknown flag
+  or command, a missing argument) now prints a fix line naming `loam <command> --help` and the code
+  line `invalid-option  ·  loam explain invalid-option` under commander's own message, like every
+  other refusal. stdout stays empty, exit 1; the `--json` envelope is unchanged.
+- README's `.github/workflows/fleet-edges.yml` **pins loam to an exact version** (`LOAM`) and says
+  how to move the pin, **adds an oasdiff step** per changed `services/*openapi.yaml`, and no longer
+  labels the `diff` step "did you break a consumer?". `test/docs-drift.test.ts` keeps the pin equal
+  to the version README names.
+
+### Contributors — release preflight and test harness
+
+- `npm run release:check` checks that every dependency a `package-lock.json` entry names resolves
+  to another entry, the way Node looks it up, and then runs `npm ci --dry-run --offline` on a
+  scratch copy of `package.json` and `package-lock.json` (new `scripts/lockfile-check.mjs`): the
+  check that would have refused `0.2.0-alpha.8`'s stripped lockfile before the tag instead of after
+  it. The structural walk comes first because npm's own verdict depends on the npm asked: npm 11
+  refuses that lockfile, npm 10 (Node 22.22.3) installs it.
+- The test harness creates its temporary directories under the canonical (symlink-resolved) temp
+  root, so the suite passes on macOS without a `TMPDIR` override.
+
+### Changed — a federated verification record is one file per service (a file-format event)
+
+- **New path written: `features/<FEAT>/verification/<svc>.yaml`.** `loam verify <FEAT> --service
+  <svc> --record` (and `--results` / `--contract-results` under `--service`, and the bound form that
+  substitutes `--service` from loam.json) now writes that service's attestation to a file of its
+  own instead of into one shared `verification.yaml`. Each file is a `schema: 2` record holding
+  exactly one attestation and that service's answers; the directory is the record, and the verdict
+  and counts are computed from the union of its files when anything reads it. What a repo notices:
+  two teams recording two different services on two docs-repo branches no longer conflict when
+  their PRs merge — the shared file conflicted every time (add/add from an empty start, content
+  conflicts on `summary:`, `claims:` and `attestations:` once one attestation had landed).
+- **Old path still read, forever: `features/<FEAT>/verification.yaml`**, active and archived, in
+  every shape loam has written. A one-file federated record reads exactly as before until a service
+  records again; that service's new file then supersedes its share of the old one (the old file is
+  not rewritten), and the write that leaves nothing in it counting removes it. An all-at-once
+  (schema-1) record is removed by the first `--service` write, which lists its answers in
+  `discarded` — the same answers the old overwrite listed.
+- **The all-at-once form is unchanged on disk.** `loam verify <FEAT> --record` without `--service`
+  still writes the one file `verification.yaml` — it answers the whole checklist from one place, so
+  there is no second writer to collide with and no service to name a file after — and is still
+  refused `record-federated` over any record carrying attestations, now including per-service files.
+- **When services answered different versions of the checklist**, a record kept as per-service files
+  counts the answers of the files that answered the version the feature asks NOW — `loam verify`
+  (read and `--record`), `loam tasks`, and `status`, `list` and `gate` for an in-flight feature all
+  derive it — and falls back to the newest file (by `recorded` date, a later service id breaking a
+  same-day tie) only for an archived feature's frozen view or when no file answered the current
+  version. The others stay in `attestations` and are named by `verify.checklist-forked` until they
+  record again — now on the recording run's own output (`notices` under `--json`) as well as the
+  read view, so the service whose answers a tally leaves out is named where the tally is printed. A
+  same-day record from a service with a later id against an older checklist no longer drops the
+  current answers and makes every reader call the record stale. A one-file record keeps its old
+  reading. The `verify.checklist-forked` message no longer suggests accepting the split.
+- **`record-unreadable` names the file that failed and the repair that is safe for it.** Git conflict
+  markers in any record file are detected before the YAML is parsed and named with their lines. A
+  service's own `verification/<svc>.yaml` is that service's word alone, so its advice is to repair
+  it or delete it and record that service again; the one-file `verification.yaml` may hold other
+  services' attestations, so its advice is to repair it or restore it from version control (after a
+  merge, the copy on the branch you merged into) — never to delete it. The old advice ("delete it
+  and record again") erased other teams' attestations when followed on a shared record, and a
+  `verify.record-miscounted` record's "record the answers again" looped straight back into the same
+  refusal. The same per-file advice reaches `evidence.record-unreadable`, and the `status` and
+  `gate` sentences for an unreadable record no longer say "delete it". A per-service file holding
+  anything but its own service's attestation is unreadable too.
+- **`path` in a recording `verify --json` payload** is the file this run wrote — the service's own
+  `verification/<svc>.yaml` under `--service`. The `path` inside `recorded` on the read and frozen views, and the
+  `verification` artifact's `path` in `status`, name the `verification/` directory once it exists,
+  the one file otherwise. `archive` and `unarchive` carry the directory with the feature they move.
+  No code or flag was added, changed or retired, and no payload key was added or removed. What
+  changes is the VALUE of four `path` keys, and each may now name a DIRECTORY: `path` on a recording
+  `verify --json`, the `path` inside `recorded` on the read and frozen views, the `verification` artifact's
+  `path` in `status --json`, and the `path` on a `next.verify` step in `status --json` (which follows
+  the artifact's). A script that opens one of them as a file must now expect
+  `features/<FEAT>/verification` — a directory — once any service has recorded under `--service`.
+- **A loam older than this release does not read `verification/<svc>.yaml`.** It sees only
+  `verification.yaml`, so `status`, `gate` and `verify` under an older pin report a feature recorded
+  this way as having no record (`gate --strict` then exits 1 on `gate.feature-unverified`), and an
+  older all-at-once `--record` writes a `verification.yaml` that this release ignores beside the
+  directory (its answers carry no attestation). Upgrade every repository that records or gates a
+  feature together — the docs repo's pipelines and each service repo's pin.
+- **`features/<FEAT>/verification/` is loam's from this release.** Every non-dot `*.yaml` in it is
+  read as one service's attestation file, and one that is not (a hand-made `k6.yaml`, say) is
+  `record-unreadable`: `verify` refuses and `status` shows the record as unreadable. Keep anything
+  else beside the feature, not inside that directory.
+
+### Changed — `verified` means a run of the stamped scenario, and the runner-neutral path is findable
+
+- **A cucumber run must have run the stamped scenario's step count.** `verify --results` used to
+  confirm a `scenario.tested` claim from any report element carrying its `@loam-digest-…` tag whose
+  steps passed — a one-step stub tagged by hand confirmed five-step scenarios. A matched cucumber
+  element must now have run exactly as many steps as `loam gherkin` emits for the scenario (`And` /
+  `But` included); otherwise the claim is `unconfirmed`, noted `ran N step(s) where the stamped
+  scenario has M`. The step text is not compared (outlines fill their placeholders in, dialects
+  differ on keyword spacing). cucumber-js's hook entries inside `steps[]` (`hidden`, keyword
+  `Before`/`After`) are read as hooks, not steps: they no longer count toward the steps, and a
+  failing one is reported `failed in a before/after hook`. `loamScenarioReport` entries carry no
+  steps and are held to their status, as before. What a repo notices: a report whose elements do
+  not run every stamped step stops confirming.
+- **A `--results` file that is not JSON is refused naming both accepted shapes.** A JUnit XML report
+  died with the parser's raw "Unexpected token '<'". It is still `answers-unreadable`, and the
+  message now says the file is XML or not JSON and names what `--results` reads: cucumber JSON
+  (cucumber-js, cucumber-jvm, behave, SpecFlow/Reqnroll, pytest-bdd `--cucumberjson`, godog) or
+  loam's runner-neutral `{"loamScenarioReport": 1, …}`. A `--contract-results` file that is not JSON
+  names its one shape the same way.
+- **`loamScenarioReport` is named wherever cucumber is.** The `--results` description in
+  `loam verify --help` now reads "cucumber JSON, or loam's runner-neutral loamScenarioReport JSON for
+  any other runner"; the `check` in the `done` block `loam tasks` prints for a `scenario.tested` unit names both
+  report shapes; the `verify.scenario-attested` message's suggested command reads
+  `--results <report.json>` and names both; WORKFLOW, the verify, implement and done-check protocols
+  and the cycle `loam explain` teaches say the same. So does the `next.verify-attested` step in
+  `status --json` — its `statement` names both shapes and its `command` now reads
+  `loam verify <FEAT> --results <report.json>` (it was `--results <cucumber-report.json>`) — and
+  `loam explain next.verify-attested`.
+- **The all-at-once `--record` checks each evidence entry shaped like a `file:line`.** Without
+  `--service` it accepted any non-empty evidence — `src/foo.py:1` for a file that does not exist —
+  and printed `verified`, while the federated form refused the same citation. An evidence entry of
+  an agent-confirmed answer that is shaped like a `file:line` (one token ending in `:<digits>`, not
+  a URL) must now be a canonical relative path to a regular file inside the repository loam.json was
+  found in, with that line in it; otherwise `answers-unevidenced`, exit 1, where it used to be
+  recorded. Every other entry — prose ("manual QA by Alice"), a URL, a path with no line — is
+  recorded exactly as before. The form still binds to no commit and stamps no pins. Evidence that
+  lives in another service's repository is recorded from there, with `--service`. A missing cited
+  file is now named in the repository's own spelling ("does not exist in this repository") in both
+  forms, never through the machine's absolute path.
+- No code, flag, path or payload key was added, changed or retired.
+
+### Added — `loam gate --since <ref>`: the deploy gate no longer forgets a feature at archive
+
+- **`loam gate` used to grade in-flight features only**, so a feature left the verification check
+  the moment it was archived — and `loam archive` reads no verification record, by design. On the
+  example fleet `gate --service order-service --strict` went from exit 1 (FEAT-112 unverified) to
+  exit 0 after `loam archive FEAT-112`; a contract-only feature escaped even a vouched service,
+  because `content_digest` covers the spec bodies and not `openapi.yaml`/`asyncapi.yaml`. Without
+  the new flag that is still exactly what the gate does, and `--help`, WORKFLOW.md and
+  `loam explain gate.feature-unverified` now say so.
+- **New flag `--since <ref>`** on `loam gate`: a docs-repo git ref — the docs commit the pipeline's
+  last deploy recorded. Every feature archived after it that carries a `specs/<service>/` delta is
+  graded too, by its frozen verification record, under the existing warn-only
+  `gate.feature-unverified` (or the reused `verify.scenario-attested`). "Archived after" means its
+  `features/archive/<FEAT>/` directory is absent at the ref, or differs from what it held there —
+  committed since or not — so a feature unarchived, edited and archived again is graded as the new
+  ship it is, not skipped as one an earlier deploy answered for. When git will not say what changed
+  under `features/archive/`, every archived feature touching the service is graded. Its message
+  names the ref and points at `loam unarchive <FEAT>` rather than a `loam verify --record` an
+  archived feature refuses. The ref is read from the docs repo's own git exactly as
+  `loam diff --base` reads its base, and refused the same way: `repository-unavailable` when git
+  cannot answer from the docs repo (or cannot list `features/archive/` at the ref), `unknown-target`
+  when the ref names no commit. No new code; no deployment state is stored.
+- **An archived record is held to the checklist its feature shipped with.** A record gone stale
+  before the archive (a scenario appended after it was written) read `stale`/`unverified` in flight
+  and `verified` with no finding once archived, because an archived record is never judged against
+  a checklist re-derived after the merge. `loam archive` now writes the digest of the checklist a
+  fresh `loam verify` derives just before the merge — when the feature carries a readable record —
+  into its snapshot manifest as a new key, **`checklist`**, in
+  `features/archive/<FEAT>/.loam-before/manifest.json` (additive: the manifest stays version 3,
+  `unarchive` ignores the key, and an older loam reading the manifest is unaffected). `gate --since`
+  grades the frozen record against it: a record answering an older checklist is `state: "stale"`,
+  `verdict: "unverified"`, with a `gate.feature-unverified` saying the feature moved after its
+  record was written. A manifest without the key — an archive made by an older loam — is graded as
+  before, as frozen history, and the row says so. `list`, `status` and `verify` keep reading an
+  archived record as frozen history, never stale.
+- **New `--json` payload keys:** top-level `since` — `{ ref, commit }` under `--since`, `null`
+  without it — and, only on a row `--since` added, `features[].archived` (`true`) and
+  `features[].checklistAtArchive` (the captured digest, or `null` when the archive captured none).
+  An in-flight row carries neither key, so a payload without the flag is unchanged apart from
+  `since: null`. The text view titles the block "verification — in flight, and archived since
+  <ref>", marks those rows `· archived`, and adds a line under a recorded row whose archive
+  captured no checklist.
+- **The MCP `loam_gate` tool** gains the matching `since` string argument.
+
+## [0.2.0-alpha.8] - 2026-09-21
+
+The work packet: the verify checklist read forwards. Still a prerelease on the `alpha` line.
+**Not published (noted 2026-10-10):** the `v0.2.0-alpha.8` tag was cut, but its release run failed at
+`npm ci` — npm on Windows had stripped other platforms' optional packages from the tagged commit's
+`package-lock.json` during the version bump (restored on `main` the same day) — so the publish never
+ran. `npm i @ybotok/loam@alpha` does not install this version, and `npm view @ybotok/loam dist-tags`
+is the record of what does. Everything in it is additive — no stable code was added,
+changed or retired, no existing flag, path or payload key moved, and nothing a repository has
+committed needs to change. What a repo NOTICES after upgrading: one new read-only command
+(`loam tasks`), new keys on two `--json` payloads it may already consume, and a corrected SCHEMA
+sentence about how scenario digests are salted — the code did not move, the sentence did.
+
+### Added — `loam tasks`, the derived answer to "what do I do next, and what closes it"
+
+The question an authored task file answers is a good one; the file is the wrong place to answer it,
+because a second mutable state drifts from the spec it was copied out of. So this is that answer
+DERIVED — the `loam verify` checklist read forwards, one work unit per promise the feature makes,
+each carrying the step it is waiting on and the fact that retires it, recomputed on every run from
+the delta, the generated suite and the verification record. SCHEMA's "Deliberate limits of the
+workflow surface" row refusing an authored `tasks.md` as authoritative state **stands unchanged**;
+this is the projection that row has always pointed at, and it is a projection precisely so that
+nothing here can disagree with the documents it was derived from.
+
+- **New read-only command `loam tasks <FEAT> [--service <id>] [--next] [--json]`.** It writes
+  nothing, anywhere, ever, and creates no artifact. Every unit it reports is one claim of the same
+  checklist `loam verify` derives, **under the same id** — a unit and the answer that closes it are
+  one identity on both commands. The one unit with no claim behind it is minted for an ADDED or
+  MODIFIED requirement carrying no scenario at all (kind requirement.described): nothing to test
+  means nothing for the checklist to ask, and a promise with no acceptance criteria is still work.
+- **`units[]` is the projection**, one entry per unit, carrying `id`, `kind`, `subject`, `at`,
+  `claim`, `dependsOn[]`, a `done` block, and — where the ledger has them — `digest`, `operation`,
+  `token` and a `source` naming the document, the 1-based line and, for a scenario, its body
+  verbatim.
+- **`at` is the step the unit is waiting at**, one of `describe`, `generate`, `implement` or
+  `attested` — never a percentage. It is spelled `at` rather than `stage` or `verdict` on purpose:
+  both of those already mean something else on payloads an agent reads beside this one.
+- **Done is a fact, not a tick.** A closed unit stops appearing, and exactly one thing closes one: a
+  claim recorded `confirmed` in a `verification.yaml` that is **not stale** against the current
+  checklist. A stale record closes nothing — the words moved under the answers. An agent-attested
+  scenario never vanishes: it stays visible at `attested`, because attested is not verified and a
+  work list that hid the difference would be the gate that teaches everyone to say yes.
+- **`frontier` is the ids of the first ten open units in derived order**, providers before consumers
+  on the exact token join `c4.calls.token == api.exposes.operation` — never a reading of prose —
+  with `frontierElided` saying how many open units it left off. **The order is advice and never a
+  lock**: nothing is assigned, nothing is reserved, and working out of order is legal and invisible
+  to every other command.
+- **`--next` is the leaf packet**: the same payload with `units` narrowed to the frontier head, and
+  what an orchestrator hands one coding agent. Everything else is left whole on purpose, so a cheap
+  model handed one unit cannot read it as the whole job. The text view prints that leaf in full —
+  the scenario's Given/When/Then verbatim and never reflowed (those are the bytes the digest was
+  taken over), its digest, the `done` block whose `check` is the fact that closes the unit, and the
+  literal follow-up command. Literal rather than a shape to fill in, because "the appropriate verify
+  invocation" is a guess the reader will get wrong.
+- **`--service <id>` is a pure lens** over the same derivation, and adds `waitingOn[]`: the open
+  units in OTHER services that this service's units depend on.
+- **`stamps` is `read` or `unknown`.** `unknown` means the bound service repo's generated suite could
+  not be read — could-not-look, and never nothing-wrong.
+- **The rest of the payload**: `feature`, `service` (the lens, or null), `services[]`, `path`,
+  `intent`, `checklist` (the digest of the question set the units derive from), `record` (`absent`,
+  `recorded`, `stale` or `unreadable`), `size{requirements,scenarios,operations,messages,calls}` —
+  the size of the DELTA and never of the open work, so that "this feature is small" and "this
+  feature is nearly done" cannot become one sentence — `contracts{expose[],call[]}`,
+  `counts{open,done,attested}`, and `review[]`, the four instructions for re-deriving this answer
+  and reviewing it.
+- **A broken `delta.likec4` or contract axis exits 1 with `ok: true`**, naming what it could not read
+  in `unreadable` (`architecture`, `contracts[]`). That is `loam delta`'s own rule rather than a new
+  one: a feeder that could not be read empties the packet, an agent consuming an empty packet reads
+  "nothing to do", so the envelope stays informative and true while the exit code stops a pipeline
+  building on it.
+- **New MCP read-only tool `loam_tasks`**, declaring `readOnlyHint` like every other read tool; the
+  base table is fifteen tools where it was fourteen.
+- **No stable code was added, changed or retired, and no existing flag, path or payload key moved.**
+  The change is purely additive: everything `loam tasks` reports is a projection of state other
+  commands already derive and grade.
+
+### Added — `loam delta --json` carries the joins and the lines it had been dropping
+
+- **New additive keys per requirement**: `line` (where it sits in the document it was parsed from, so
+  a consumer can send an author to the line rather than to the file), `basedOn`, `requires`,
+  `capabilities`, `realizes`, `publishes` and `consumes`. Every one of them is already written on the
+  requirement and every one names work — which permission gates it, which capability it belongs to,
+  which named promise it realizes, which messages it produces and consumes — and an implementer
+  handed this projection had to go and read the Markdown it claimed to have projected to find them.
+- **New additive keys per scenario**: `line`, and `digest`, the 16-hex scenario body hash. That
+  digest is the exact join key the rest of the toolchain already uses — the `@loam-digest-<16hex>`
+  tag `loam gherkin` stamps and the string `loam verify --results` matches a cucumber report on — so
+  a consumer of this brief can now name the test that answers an acceptance criterion instead of
+  regenerating the suite to find out. It is salted by the owning service and the axis, like every
+  other spelling of it, so an arch requirement's scenarios digest differently from identically
+  worded business ones.
+- **Nothing existing moved.** Every key this payload already carried is untouched, the text output is
+  unchanged, and no stable code was added or changed.
+
+### Added — `loam gherkin --json` says which stamp belongs to which scenario
+
+- **New additive key `files[].stamped`**, a list of `{scenario, digest}` pairs. `digests` was a bare
+  array and `scenarios` a bare count, so the one thing a consumer needed — which stamp belongs to
+  which scenario — was the one thing this payload could not say, and the only way to learn it was to
+  read the generated file back off disk. A `kept` row reads its pairs off the file that is really on
+  disk, because its numbers describe the in-flight emission that stayed rather than the one that was
+  withheld.
+- **`digests` and `scenarios` are unchanged beside it**, and no stable code was added or changed: the
+  envelope permits adding a key and never changing one.
+
+## [0.2.0-alpha.7] - 2026-09-07
+
+Infrastructure belongs on the fleet map, and the render is navigable at fleet scale. Still a
+prerelease on the `alpha` line: `npm i @ybotok/loam@alpha` installs it. One code is REMOVED —
+`landscape.datastore-private`, the first code this project has ever retired — and no flag, path or
+payload key is. What a repo NOTICES on its first `validate --all` after upgrading: a
+`subsystem.views-stale` error against the new `architecture/services.likec4`, in every fleet whose
+map draws a service, cleared by one `loam subsystem sync`; a second one against
+`architecture/subsystems.likec4` wherever subsystems exist, because those views gained boundary
+edges and an `of` subject; and silence where a datastore drawn beside the services used to be told
+to move.
+
+**Upgrading: one `loam subsystem sync` per docs repo, once.** `loam validate --all` reports
+`subsystem.views-stale` (error) against the new `architecture/services.likec4` in EVERY existing
+docs repo whose fleet map draws a service — flat fleets with no subsystems included, because the
+file is new everywhere and an absent generated file is a state of its own. This is not a
+subsystems-only upgrade: a fleet that has never run `loam subsystem new` gets the finding too. A
+repo that DOES have subsystems gets a second finding on the same run, against
+`architecture/subsystems.likec4`, because the subsystem views gained boundary edges and an `of`
+subject and every existing copy therefore re-renders differently. One `loam subsystem sync` writes
+both files and clears both findings. `loam archive` names the same repair rather than claiming
+"complete + current". Nothing else in a repository has to change, and no document a team wrote is
+touched — and a document a team wrote that is already standing at one of the two generated paths is
+refused by name rather than overwritten (below).
+
+### Removed — `landscape.datastore-private`, because where a store is drawn is the team's choice
+
+- **`landscape.datastore-private` (warn) is retired.** It fired on a `database` element drawn at
+  fleet level with exactly ONE consumer, and its whole message prescribed deleting the peer and
+  writing the store inside its owner. The identical store nested was silent, so the check graded the
+  DRAWING and not the architecture — a restriction rather than a fact about the fleet. A store one
+  service owns may now be nested under that service's element or drawn beside the services, and loam
+  grades neither. The code is not in the frozen `ErrorCode` or `IssueCode` unions, so removing it
+  breaks no contract; `loam explain landscape.datastore-private` no longer answers, and the row is
+  gone from the agent-facing check table.
+- **`landscape.datastore-shared` (warn) is unchanged**, both arms. Two or more services on one store
+  is a fact about coupling, not a restriction, and it fires at two consumers for both placements
+  alike. What survives from the retired code's message is the one clause that was a fact about
+  LikeC4 rather than a preference, and SCHEMA's "Private stores" now leads with it: a second
+  consumer's edge resolves only against a declaration the MAP holds, because a per-service project
+  is `architecture/` plus one model.
+- **Infrastructure is not a service.** A new `INFRA_KINDS` set in `core/vocabulary/maturity.ts` —
+  `database`, `queue`, `topic`, `cache`, `bucket`, compared case-insensitively — takes such an
+  element out of four surfaces at once: the drawn-service census behind
+  `landscape.service-undocumented`, the `loam gate` partner set (an infra endpoint is dropped from
+  the `partners` payload, exactly as an actor already was), the `loam verify` checklist (a
+  fleet-level store no longer mints a `service.exists` claim no repository can answer), and the
+  scorecard's element denominator, whose `c4` row now counts services rather than services plus
+  their stores. The hook is the kind NAME, with the same limitation `ACTOR_KINDS` lives with: a
+  fleet spelling its kind `postgres` is not covered, and a tag can be added later as a second
+  spelling. A store BOUND to a directory with `metadata { service }`, or titled like one, stays an
+  adopted service on every one of the four surfaces — the census predicate wins over the kind.
+  `landscape.service-undocumented`'s message gained a THIRD remedy beside "bind it" and "tag it
+  `#external`", spelled from the same set: neither of the old two was true of a store the fleet
+  owns, and that message is the only place an author learns which kind spellings loam reads.
+- `c4.uncovered` was left alone, and the measurement is the reason: a delta drawing
+  `splitLedger = database 'split-ledger'` earns it, and adding `Covers: splitLedger` to the
+  feature's `arch.spec.md` delta silences it exactly, with no `covers.unknown`. The remedy the
+  message names is true, so this is not a residual restriction — and the code fires only on elements
+  a feature DELTA adds, never from `validate --all` over a living tree.
+- The acceptance criterion, run for real: a `database` drawn at fleet level, owned by the fleet, with
+  one consumer, no `#external` tag and no binding, now earns ZERO findings from `loam validate --all`
+  and from `loam gate`.
+
+### Added — `architecture/services.likec4`: one generated overview view per service
+
+- **New generated path `architecture/services.likec4`**, written by `loam subsystem sync` beside
+  `architecture/subsystems.likec4`, removed by it when the fleet map draws no service, and owned
+  outright by loam: views only, byte-reproducible, one view per service the map resolves, sorted by
+  service directory id. Each view is declared `of` its service's element, which is what makes the
+  fleet map, every subsystem view and every other service view click-through into it with no
+  authored link — measured at likec4 1.59.2. Peers are NAMED one by one rather than wildcarded,
+  because on a map that groups its services the wildcard form collapses every peer to its group box
+  and yields no drill-down at all (measured on a 120-service fleet: 0 of 10 nodes navigable). Median
+  at 58 services in 11 groups: 10 nodes, 8 edges per view, about 7 ms of layout each.
+- **Titles are folders.** A per-service view is titled `<subsystem path> / <service directory id>`,
+  built from the same path helper the subsystem views use, so both generated files fold into one
+  browser folder tree mirroring `services/`. LikeC4 has no view-folder syntax — `views { group … }`
+  is a parse error at the pin — and splitting the title on `/` is the whole mechanism.
+- **An authored view of the same element keeps precedence.** Two views `of` one element are legal;
+  the first document alphabetically wins the default navigation target and both stay reachable,
+  because the subject's own node cycles to the other. `architecture/landscape.likec4` sorts before
+  `architecture/services.likec4`. loam does not detect the authored view and never will:
+  docs/DESIGN.md rule 26 forbids reading what a view SHOWS.
+- **Subsystem views gained two things** in the same generator: `include <member> -> *, * -> <member>`
+  per member, so a subsystem view answers "what does this group touch" and not only "who is in it",
+  and `view subsystem_<name> of <ancestor>` when the map holds an element owning exactly that
+  subsystem's members. Measured at 58/11: ~14 nodes, ~38 edges, 12 of 14 nodes navigable. Every
+  existing `architecture/subsystems.likec4` therefore re-renders differently and is stale once.
+- **`subsystem.views-stale` now grades two files**, one finding per file, each naming its own path in
+  `subject`, `locations[0]` and the message. No new code was minted: both files are written by one
+  command in one commit and repaired by one run, which is what makes one code honest.
+- **`subsystem.view-id-collision` reserves `service_` as well as `subsystem_`.** A `service_` id is
+  reserved only for a service the fleet map actually DRAWS, so an unmodelled `services/<id>/`
+  reserves nothing; the message names which generated file and which prefix.
+- `deployment.doc-reserved` refuses a feature deployment document named `services.likec4` for the
+  same reason it already refused `subsystems.likec4`: both names are generated, overwritten
+  wholesale, and parsed by nothing.
+- **No writer overwrites a generated views file it did not write, and refusing is now an exit 1.**
+  Both generated paths are filenames loam RESERVES inside `architecture/`, a directory the team
+  owns, and every writer of them rewrites the file whole — so a repository that already kept a
+  hand-authored diagram at one of those paths would have lost it, silently, on the first run after
+  the release that reserved the name. Reproduced before the guard existed: with a hand-authored
+  `architecture/services.likec4` in the tree, `loam subsystem new platform` printed
+  `architecture/services.likec4 updated` and destroyed it, first line and all.
+- **What makes a file loam's is its FIRST LINE**, `// generated by loam`, with a leading byte-order
+  mark stripped before the test — a Windows editor adds one without changing a fact, and without the
+  strip loam would call its own output authored and refuse to regenerate it for good. A hand EDIT of
+  a generated file keeps that line, so it is still loam's to repair and one `loam subsystem sync`
+  puts it back: that has always been what `subsystem.views-stale` says. Only a file that never
+  carried the mark is somebody else's. **A 0-byte file at either path counts as somebody else's** —
+  it carries no mark — so an empty `architecture/subsystems.likec4` or
+  `architecture/services.likec4` is no longer filled in; delete it and re-run.
+- **`loam subsystem sync` declines the one file and finishes the rest.** `--json` reports the new
+  `action` value **`refused`** — on `action` for `architecture/subsystems.likec4`, on
+  `serviceViews.action` for `architecture/services.likec4`, one predicate behind both — while the
+  other generated file, the per-service project files and the root `exclude` are still done and
+  still reported, and the **exit code is 1**. That is `loam validate`'s shape rather than a refusal
+  envelope, and the non-zero exit is the point: `loam validate --all` goes on reporting
+  `subsystem.views-stale` for that path with `loam subsystem sync` named as the repair, so a run in
+  a hook or a CI step must not report success over a file it can never fix.
+- **`loam subsystem new` / `rm` / `move` / `rename` and `loam seed` refuse WHOLE**, before a byte is
+  staged: `error.code` `already-exists`, exit 1, nothing written and — for `move` and `rename` —
+  nothing renamed. No new code was minted, because that is what `already-exists` has always meant on
+  these verbs; `loam seed` can answer it for the first time. They refuse whole rather than per-file
+  because their entire contract is that the generated files land in the SAME commit as the change,
+  so completing the structural half would manufacture the very `subsystem.views-stale` state that
+  commit window exists never to leave behind — irreversibly, for a `move` that also stages renames.
+- **The refusal sentence is one sentence, verbatim from all five writers.** It names the mark loam
+  looked for, says that not one byte changed, and gives the way out: rename the file to a name loam
+  does not reserve — every other `.likec4` under `architecture/` renders in the same project, so the
+  diagram is not lost — or delete it, then re-run.
+- **Payload keys, all additive.** `loam subsystem sync --json` keeps `path` and `action` meaning the
+  subsystem file and adds `serviceViews: { path, action }`; `loam subsystem new` / `move` / `rm` /
+  `rename --json` keep `views` and add `serviceViews`; `loam archive --json` keeps
+  `subsystemViewsStale` and adds `staleViews: string[]`, the generated files it left behind. Nothing
+  existing changed meaning.
+- The generated-file SET is now one table (`GENERATED_ARCHITECTURE_FILES`), read by the path
+  builders, the name reservation, both project loads that must EXCLUDE these files (the fleet map's
+  and `c4.fleet-project-invalid`'s), archive's staging and `loam seed`'s. Four readers that must
+  never disagree about which files are generated, and a name in one but not another failed silently
+  both ways while there was only one.
+
+### Added — the intra-service use-case slot, published rather than graded
+
+- **`loam adopt` briefs `services/<…>/<id>/usecases/<name>.likec4` as an OPTIONAL target**, with the
+  tag grammar and a worked example: a `dynamic view` tagged `#req-<Requirement-ID>` as the first
+  thing in the view body, the tag declared once (in the landscape's `specification` for an extending
+  model, in the model's own for a standalone one), every hop backed by a relationship the model
+  declares, and the view id namespaced by the service because an extending model's views share the
+  root project's flat id namespace. Optional-and-absent prints lowercase `missing` and is not a
+  finding — the existing mechanism for an optional artifact, not a new one.
+- **The generated AGENTS.md names the slot and its title convention**,
+  `'<subsystem path> / <service id> / <use case>'`, so an authored use-case view lands in the same
+  browser folder as its service's generated overview.
+- **No new finding code, and no check on absence.** docs/DESIGN.md rule 26 — presence is never owed,
+  and no check may grade a view's absence — is enforced by `scripts/arch-check.mjs`, so there is no
+  service.usecases-missing and there never will be. The grader (`c4.valid`'s
+  ` · K tagged flow(s) graded`) has existed since 2026-09-03; all that was missing was anyone being
+  told. A usecase.flow-untagged check, which would grade a view that EXISTS, is recorded on
+  [ROADMAP.md](ROADMAP.md) with its promotion bar rather than built.
+
+## [0.2.0-alpha.6] - 2026-09-04
+
+A service model may extend the fleet map, and the nine problem reports one fleet filed against the
+previous release are closed. Still a prerelease on the `alpha` line: `npm i @ybotok/loam@alpha`
+installs it. Nothing below removes a code, a flag or a payload key; two things a script may have
+read do move: every LikeC4 line number loam prints is 1-based now, and seven feature-delta codes
+plus the feature arm of `usecase.flow-invalid` answer `--feature <FEAT-id>` in
+`loam explain --json` where they answered `--service <id>`. What a repo NOTICES on its first
+`validate --all` after upgrading: a model written in the extending shape earns the renderer-wiring
+warnings until one `loam subsystem sync` — which now also deletes a stray per-service
+`likec4.config.json` beside such a model — a root `exclude` that hides the map is
+`landscape.excluded`, and a standalone model whose copies of the map's elements disagree with it
+is `c4.declaration-diverged`; a repository whose models all stand alone is asked to migrate
+nothing, and its root `exclude` is not touched.
+
+### Fixed — one rule for a service's own edge, and the document that actually failed, on every surface
+
+- `loam context` and `loam explore` name the `architecture/` document that ACTUALLY failed in their
+  printed warning, off the `landscape.broken` key their `--json` payloads already carried. `parses`
+  answers for the PROJECT, so with a broken sibling the landscape file has no errors at all — and
+  both printers still said `architecture/landscape.likec4 does not parse`, a claim about bytes loam
+  had read fine. `explore`'s absent arm keeps the file name: `present` is about the FILE, which is
+  the write target every brief asks for edits to.
+- An edge whose two endpoints resolve to the SAME service is that service's own internal wiring,
+  and no surface files it as an inbound call any more. `loam adopt --json` already dropped it; the
+  one shared derivation does now, so `loam context`, `loam explore`, `loam show` and
+  `loam vouch --pack` stopped reporting a service as its own caller (`← <id> "reads"`), and
+  `loam list`'s fleet-wide spelling of the same rule stopped reading an `op`-carrying self-edge as
+  proof that somebody calls the service — a service nobody calls was told it owed an OpenAPI
+  contract, grading `partial` in `list` while `context` said `documented`. `landscape.touched` and
+  `landscape.service-isolated` are unchanged: they read the relationships, so the map still draws
+  an edge on the service.
+- The adopt brief's `service.model-excluded` row describes both entry shapes: one covering the
+  DIRECTORY, which `loam subsystem sync` rewrites, and one shaped like a FILE
+  (`services/**/model.likec4`), which sync cannot repair and has to be removed or narrowed by hand.
+  The finding's own message already said which one you have; the brief promised sync for both.
+- `loam diff` classifies a base ref's tree with the same reserved-directory rule the live walk uses
+  (`adrs/`, `usecases/`, `ui/` — shared as one set, not respelled). A service directory holding only
+  the `services/<id>/usecases/` slot used to be absent from the base AND to contribute a phantom
+  service called `usecases`, so committing it and diffing the unchanged tree reported one addition
+  and one removal.
+
+### Added — one model, many documents: a service model may extend the fleet map
+
+- `services/<…>/<svc>/model.likec4` now comes in two shapes, and the FILE's own grammar decides
+  which — never a config key, never a flag. A model declaring no `element` kind inside a top-level
+  `specification { }` block is an **extending model**: loam parses it inside the `architecture/`
+  project and it says what is inside the service with `extend <fully-qualified id> { … }` on the
+  element the map already binds to the directory, re-declaring no kind, no tag and no partner. A
+  model that declares one is a **standalone model**, parsed alone exactly as every model was
+  before — legal forever, and not what `loam adopt` briefs any more. SCHEMA.md's new
+  "Two shapes of a service model" carries both, the grades below, and the ordered migration recipe.
+- New `c4.declaration-diverged` (warn, service target, subject the service, one finding per element):
+  a STANDALONE model and the fleet map (`architecture/`) both declare one element, and the
+  two copies disagree about `kind`, `title`, the tag SET or the `metadata { service }` binding. The
+  message prints both declarations, names which fields differ, and offers the two repairs — copy the
+  map's declaration verbatim, or migrate to the extending shape. `description` is deliberately not
+  compared: it is prose nothing grades, while the other four each change what a view shows or what
+  loam resolves. Silent while the map does not parse. This is the check that had no code: a fleet's
+  copies of `kafka` and its identity provider had already lost `#platform` on every copy but the
+  map's, and nothing in loam read two documents together.
+- New `c4.element-unowned` (warn, service target, subject the service, one per element): an
+  EXTENDING model declares an element outside the element that resolves to its own service. A system
+  the service reaches belongs in `architecture/landscape.likec4`, declared once; another service's
+  internals belong in that service's model.
+- New `c4.fleet-project-invalid` (warn, `landscape` target, subject the service whose directory
+  holds the file): `--all` only, only when at least one extending model exists, the map itself
+  parses, and no root `exclude` entry hides the map (`landscape.excluded` below is then the whole
+  answer). loam loads every `.likec4` the root LikeC4 project reads except the generated
+  `architecture/subsystems.likec4` — the map, its siblings, every extending model and every
+  `.likec4` beside one — and reports each error that is NOT already present in the map alone, in a
+  per-service project, or in a service-flow project the same run made. That difference is the class
+  no per-service grade can see: two services each declaring `tag req-AUTH` locally, two models
+  adding the same child id under one element, a broken untagged sibling nobody opted in. All three
+  are renderer-fatal and all three were silent.
+- Three new renderer-wiring warnings on the `landscape` target, root-gated like
+  `service.likec4-config-missing` and repaired by the same `loam subsystem sync`:
+  `service.likec4-config-stray` (a `likec4.config.json` beside an EXTENDING model — the renderer
+  registers a project holding nothing, or holding the model alone where it cannot parse),
+  `service.model-excluded` (the root `likec4.config.json`'s `exclude` covers an extending model's
+  directory, naming the entry that does it, so the renderer never loads the model) and
+  `service.model-unexcluded` (it does NOT cover a STANDALONE model's directory, so the renderer
+  merges that model into the map and reports every kind and element it declares as a duplicate —
+  blanking the whole root project, not one service).
+- New `landscape.excluded` (warn, `landscape` target, `loam validate --all`) — the root
+  `likec4.config.json`'s `exclude` covers `architecture/landscape.likec4` itself. loam keeps
+  grading the map whatever that list says, so every finding in the run is right; the renderer does
+  not, and until now nothing said so. A repo notices it as one line at the top of `validate --all`
+  naming the entry verbatim — typically an `architecture/*.likec4` written for a palette — INSTEAD OF
+  the `c4.fleet-project-invalid` cascade the same entry used to produce, and it is the only line in
+  the run that names the cause. `c4.fleet-project-invalid` is not graded while the entry stands: that
+  check loads the fleet project the way the renderer does, with no floor under the map, so the one
+  line came back as an unresolved `extend` in every extending model — 161 warnings on the packaged
+  five-service example. Its message says the fleet project is unread rather than clean, and grading
+  resumes the moment the entry goes. Never gating: with the map kept by the loader, every fact loam grades holds
+  identically either way. The repair is the team's own edit — `loam subsystem sync` maintains only
+  the `services/` entries and will not touch it, and the message says so rather than sending its
+  reader to a command that reports success and changes nothing.
+- `loam subsystem sync` now maintains the root `likec4.config.json`'s `exclude` as well as the
+  per-service files. It rewrites the list to hold `services/<tree>/**` for exactly the models that
+  stand alone: the wholesale `services/**` and every `services/<tree>/**` naming a directory that IS
+  a service are removed, every other entry is kept in the order the team wrote it (a
+  `services/legacy/**` for a directory that is no service survives), and the standalone entries are
+  appended sorted. It runs when at least one extending model exists or when a standalone model's
+  directory is not covered, so a repository whose models all stand alone behind `services/**` is
+  never touched. Same staged transaction as the rest of `sync`; `--json` gains the additive
+  `projects.exclude` (whether it rewrote, the resulting entries, and what was added and removed) and
+  the text view prints one line when it did. A root config that is not JSON is left alone with a
+  printed note.
+- `loam init --docs <path> --create` now scaffolds `likec4.config.json` with
+  `exclude: ["**/node_modules/**", "features/**"]`. `services/` is deliberately not excluded — the
+  models a fresh repository writes extend the map, and the root project is the only place they
+  parse. A feature's `delta.likec4` keeps its own `specification` block and stays excluded.
+- The landscape the scaffold writes teaches the extending shape. Its `views` paragraph told a fresh
+  repository that a service model "renders from its OWN directory" and that "each declares its own
+  `specification` block, so the renderer can only be given one of them at a time" — written before
+  an extending model belonged to the root project, and printed in the same `loam init --docs .
+  --create` run that now excludes `features/**` precisely because it does. And the check that says
+  a map is still untouched scaffolding now accepts EVERY generation loam has shipped, not just the
+  current text: it is a byte-suffix match, so rewording the comment reclassified every older
+  untouched scaffold as hand-authored — `loam seed` refused one its own scaffold had written
+  (`seed-landscape-edited`, nothing written) and `loam status` dropped the teaching rung from the
+  empty-fleet ladder. The two `v0.1.0-beta` stubs (no `views` block, no `tag platform`) and the
+  `v0.2.0-alpha.1`-through-`.5` stub are all recognised, frozen beside the writer.
+- `loam adopt --service <id>` briefs the extending shape: all four `shape` rules of the
+  `model.likec4` target are rewritten, and the `example` is a `model { extend <id> { … } }` document
+  with the fleet element's real id substituted in where the brief resolves exactly one. The brief's
+  `checks[]` gains `c4.declaration-diverged`, `c4.element-unowned`, `service.likec4-config-stray`,
+  `service.model-excluded`, `service.model-unexcluded` and `c4.fleet-project-invalid`, and its
+  renderer statement in `unchecked[]` says the root project now holds the map and every extending
+  model. `/loam-adopt` steps 3, 4 and 5 and `/loam-check`'s three fix tables carry the same.
+- The packaged example fleet (`examples/docs`, what `loam init --example` copies out) is migrated:
+  all five models extend the map, the five `services/**/likec4.config.json` are gone, the root
+  `exclude` is the scaffold's two entries, `architecture/landscape.likec4` gains `element database`
+  and the `notification-provider` system that notification-service's model used to declare for
+  itself, and every `Covers:` entry and `views` block names the map's fully-qualified ids. Its
+  `loam validate --all` result is unchanged: 0 errors and the same ten deliberate warnings.
+- `loam archive` now writes a service's OWN `model.likec4`, not just the fleet map. A delta's
+  additions nested under a service whose model EXTENDS the map — a container, a store, a
+  container-level edge — are spliced into that model's `extend <fqn> { … }` block instead of into
+  `architecture/landscape.likec4`, and a model with no `extend` block for that fqn gains one. A
+  relationship goes to the model of the service owning its SOURCE, else its TARGET, else stays on
+  the map: a service-level edge is where every fleet check reads it. A service-level element, a
+  STANDALONE model and a service with no model.likec4 keep the previous behaviour byte for byte.
+  What a repo notices: `loam archive` prints a second
+  `architecture: merged into services/<…>/model.likec4 — +N element(s), +M relationship(s)` line
+  beside the landscape one, the model path appears in the `--json` plan (and in `--dry-run`) as an
+  ordinary write, `loam unarchive` restores it from the same `.loam-before` snapshot as any other
+  overwritten file, and the service is no longer `c4.invalid` (duplicate declaration) the moment its
+  model declares the container the adopt brief told it to declare. No new payload key and no new
+  error code. Re-archiving adds nothing a second time — existence is checked against the models too
+  — and two archives touching one model's `extend` block land adjacently.
+- The archive's existence check now reads the extending models by TITLE as well as by id, so a
+  container a service already draws under a different identifier is recognised instead of being
+  spliced in beside itself: a delta adding `cache = container 'Order cache'` under a service whose
+  model already declares `orderCache = container 'Order cache'` adds nothing and leaves the model
+  byte for byte, which is what the same delta against the same title on the fleet map has always
+  done. Nothing is routed to that model, so the plan names only the landscape — the second
+  `merged into services/<…>/model.likec4` line appears when a model actually receives something.
+  The models' title join is scoped to one service — it fires only when both the model's
+  declaration and the addition resolve to the SAME explicitly bound service — because every
+  extending model in a fleet names a container `api`, and the map's global title index is a
+  pre-binding fallback, not a rule to spread.
+- An extending model with no `model { }` block — an empty file, a `views { }`-only file, a tags-only
+  `specification { }`, all three shapes loam calls extending on purpose — gains one when a feature's
+  addition is routed into it, instead of refusing the whole archive with `merge-failed`. It is the
+  same call the merge already makes one level down, where a model that has never named a container's
+  parent gains the `extend <fqn> { }` block rather than refusing.
+- `loam archive` proves the model it would write. The merged model is loaded as the project the
+  per-service grade reads it in — the `architecture/` documents with this archive's own merged
+  landscape in place, plus the model — and an archive whose model would not parse is refused at plan
+  time (`merge-failed`) with nothing written, naming the model path and the first three errors. Two
+  causes actually occur, and the refusal names both: a kind or tag the map's `specification` block
+  does not declare, and a reference to ANOTHER service's interior, which lives in that service's own
+  model and is in no project this one can see. A container-level edge whose two ends belong to two
+  different services is the case that changes: it used to merge, because both containers landed on
+  the map beside it, and it is now refused — there is no legal placement for it, and the answer is
+  to draw that call service to service.
+- What a repo notices: nothing, until a model is written in the new shape or `loam subsystem sync`
+  is run. A repository whose models all stand alone keeps every finding it had, and its root
+  `exclude` is not touched. Write one extending model — or upgrade a repo whose scaffold predates
+  `services/**` being excluded — and the next `loam validate --all` reports the renderer-wiring
+  warnings above until one `sync`; that one sync rewrites the root `exclude`, writes the project
+  file a standalone model is owed and DELETES the stray one beside every extending model, so after
+  it the renderer's project picker holds one entry instead
+  of one per adopted service, and a fleet-wide duplicate that used to blank the whole picture is
+  reported as `c4.fleet-project-invalid` before anybody opens the renderer.
+
+### Changed — a model's grades follow its shape, and `--service` reads the whole map project
+
+- `service.likec4-config-missing` is narrowed to STANDALONE models. A model that extends the map
+  belongs to the root project, so it is owed no per-service `likec4.config.json` and never earns
+  this warning; the same directories earn `service.likec4-config-stray` instead while a file left
+  over from before the migration is still sitting there, and `loam subsystem sync` — which now also
+  stops writing the file for extending models — is the repair for both. The message is reworded to
+  say which shape it is about.
+- `loam validate --service <id>` now reads the whole `architecture/` project, exactly as `--all`
+  does, instead of `architecture/landscape.likec4` alone. A use-case file under `architecture/` that
+  does not parse therefore reports `spine.landscape-invalid` on a single-service run too, where it
+  used to be visible only under `--all`. `c4.declaration-diverged` compares against that same
+  project.
+- `c4.invalid` and `c4.valid` keep their codes and change scope with the shape. For an extending
+  model every error the per-service project raises is the MODEL's — including one the parser blames
+  on `architecture/landscape.likec4`, because the map parses clean on its own — and `c4.valid`'s
+  message reads `extends the fleet map — N elements · M relationships`. When the map itself does not
+  parse, an extending model cannot be read at all: neither code is emitted for it, and
+  `spine.landscape-invalid` carries one clause more saying the model extends the map and so cannot
+  be read either.
+- `landscape.service-unmodelled` is raised on the `--service` target too, and stays an error. An
+  EXTENDING `model.likec4` says what is inside an element the fleet map binds, so a service whose
+  directory no map element resolves to has nothing to be inside and no count in the model means
+  anything: `loam validate --service <id>` reports it and exits 1 where the same tree used to come
+  back `c4.invalid` for a model read alone. `/loam-check`'s `--service` table carries a row of its
+  own for it and `loam explain landscape.service-unmodelled` answers for both scopes. A standalone
+  model is unaffected — the fleet run still owns that state.
+- `subsystem.view-id-collision`'s census covers every extending model's authored view ids under
+  `--all`, not the landscape's alone: those documents are in the same root project now, and a view
+  id claimed twice there makes the renderer refuse the whole project.
+- `spine.landscape-invalid` names the document that actually broke. The finding is raised against
+  the whole `architecture/` PROJECT and the message hardcoded `architecture/landscape.likec4`, so an
+  `architecture/usecases/x.likec4` with a typo sent every service's reader to a file that parses and
+  the real path appeared nowhere in the payload. The message now lists the broken documents
+  repo-relative and comma-separated — the spelling `landscape.invalid` already used under `--all` —
+  each `details` line carries its own file once two or more are broken, and `locations` carries the
+  first broken file as `primary` beside the service directory as `scope`. `loam explain`'s "fix the
+  file the message names" is true now.
+- `c4.declaration-diverged` finds the copies it was written for. It joined on the literal element
+  id, so in a GROUPED map — one nesting its services under a parent, as loam's own example does — a
+  standalone model's `paymentService` never met the map's `marketplace.paymentService` and the check
+  was silent on the shape it exists for. The join is now the id; then the `metadata { service }`
+  binding when both documents wrote one; then the map element whose id ends with the model's as a
+  dotted tail. A tail two map elements answer to joins nothing — a divergence reported against the
+  wrong peer is worse than the silence. The message names the other side as `the fleet map
+  (architecture/)` rather than a file it never read, and names the map's own id when it differs.
+- `c4.declaration-diverged` no longer joins a standalone model's `db`, `api` or `agent` to a
+  container the map draws INSIDE another service. The dotted-tail rung stands, and a tail that
+  carries a dot (`paymentService.api` ↔ `marketplace.paymentService.api`) is joined as before; the
+  BARE last segment is now a key only for a FLEET-LEVEL map element — one no ancestor of which
+  stands for a service, which is a top-level element and equally a box the map draws inside a plain
+  grouping element, by the same fleet-census predicate every other fleet check asks. Grouping is a
+  drawing convenience, not ownership: a `cache` the map draws inside an `infra` group is the FLEET's
+  cache, so a standalone model that declares its own top-level `cache` gives one name two meanings
+  and is reported. Only a SERVICE owns an interior. What a repo notices: a private cache called
+  `db` beside another service's `db` was warned about and told to copy that service's title
+  verbatim; it is now silent. loam's own `meta/docs` carried the workaround for it, and no longer
+  does — its `coding agent` element is spelled `agent` again.
+- `c4.declaration-diverged` stops asking for a copy that is already there — in both directions.
+  Since LikeC4 1.59.0 a kind can carry tags and every element of that kind arrives with them, so a
+  tag difference can be one no element declaration writes and no copy can fix. loam now decides that
+  by SIMULATING the copy rather than by matching one shape of it: when the tag sets are all that
+  differ and copying the map's literal tags across would leave them still differing, the message
+  says so, names `specification { element <kind> { … } }` as where they come apart, and says WHICH
+  document declares tags on that kind, so an author knows which file to open. Both shapes reach it
+  now: the model writing `#external` on an element whose map twin inherits `#external #platform`
+  from `element topic { … }` used to be told to copy the map's bare line, and doing exactly that
+  produced the other arm of the same message (measured on `examples/docs`' order-service). Grammar:
+  "the kind differs" / "the title differs" / "the tags differ".
+- Three messages say what they could not say before. `c4.invalid` on a model written in BOTH shapes
+  at once — an element kind declared in `specification { }` beside an `extend` — gains one `details`
+  line saying the kind is what makes the file standalone, so the `extend` resolves nothing, and
+  which of the two lines to drop. `usecase.flow-invalid` whose project refuses an undeclared
+  `#req-`/`#cap-` tag gains one line naming the `tag <name>` declaration that is missing and the
+  `specification { }` block it belongs in. And `c4.valid` gains ` · K tagged flow(s) graded` when
+  the service's own project declared any, so a HEALTHY intra-service flow is visible on one surface
+  instead of none. Both hints are the FIRST `details` line rather than the last: the cap is ten
+  lines in text and in `--json`, and a model written in both shapes at once produces dozens of
+  cascading errors, so the one line that diagnosed it was truncated away in exactly the case it
+  exists for.
+- A `.likec4` beside `model.likec4` that the service's own `likec4.config.json` `exclude` covers is
+  no longer read, graded or reported. loam staged every sibling regardless, so a file the renderer
+  never loads earned `usecase.flow-invalid` under a message claiming the project is read the way the
+  renderer reads it. Standalone models only — that file IS the project config there; a model that
+  extends the map is read in the root project, and a per-service config beside it is
+  `service.likec4-config-stray`. The RECURSIVE spelling counts too: a leading `**/` compiled to a
+  required `/`, so `**/usecases/**`, `**/views.likec4` and `**/*.likec4` matched nothing while the
+  renderer (measured, likec4 1.59.2) hides exactly what they name — `usecase.flow-invalid` gated the
+  run at exit 1 over a file in no project loam was reading.
+- `spine.landscape-invalid` says "a, b have N error(s)" when it names more than one document; it
+  read "a, b has N error(s)".
+- `c4.element-unowned` leads with the remedy that fits a private store. The message listed the two
+  remedies that move an element OUT of the service — the map, or another service's model — and
+  omitted the one an author usually wants: a store or component this service owns goes INSIDE the
+  `extend <fqn> { }` block, where its id becomes `<fqn>.<name>`. Following what the tool printed
+  moved a private store to fleet level and earned `landscape.service-undocumented`.
+
+### Added — problem reports carry an ordinal and a status, and `loam doctor` counts them
+
+- The `loam-report` protocol (`loam instructions loam-report`) names its file
+  `loam-reports/NNN-YYYY-MM-DD-<short-slug>.md`: `NNN` is an ordinal of at least three digits,
+  zero-padded, one
+  more than the highest already in the directory, `001` over an empty or absent one, widening past
+  three digits rather than reusing a number, and the
+  protocol tells the agent to read it from `loam doctor --json` rather than count the directory
+  itself. A path that already exists is a concurrent report claiming that ordinal — take the next
+  one; the collision suffix is gone. That check is on the PATH while the promise is about the
+  ordinal, so the protocol also tells the agent to re-run `doctor` after writing: two entries
+  sharing an ordinal means the later `Recorded` renames to the next free one.
+  The directory is `loam-reports/` beside the `loam.json` that resolved
+  (else beside the directory the agent runs in) — `reports.dir` carries it WITH that segment on the
+  end, so it is written into rather than joined onto — the ordinal is unique within it, and a
+  report is cited by
+  ordinal — in a commit message, an issue or another report's cross-references — never by filename.
+  The document template gains `- Status: open` directly after `- Classification:`, with the
+  vocabulary `open` / `sent` (handed to the author — the person forwarding a report sets it, never
+  the agent writing it) / `fixed in <version>` / `superseded by <NNN>`; a report is closed by
+  editing its own `Status` line, and there is no index to keep in step with it. Every safety
+  sentence is unchanged: `<redacted>`, "Never re-run" a writer, "do not upload", and the section
+  headings.
+- `loam doctor --json` gains one additive key, `reports`: `reports.dir` (the absolute path of the
+  `loam-reports` directory beside the `loam.json` that resolved — and, when a `loam.json` was FOUND
+  but could not be parsed, beside that file, which is the same root `agents` is inspected against;
+  only where no config file exists at or above the run directory does it fall back to the run
+  directory. The last segment is ON it, so the protocol writes inside the path rather than
+  joining the name a second time), `reports.present`, `reports.total`, `reports.next` (the ordinal
+  the next report takes, padded
+  to at least three digits and widening past them, `001` when there is none), and `entries[]` —
+  every `*.md` in the directory
+  sorted by the ordinal its name claims, numerically, with unnumbered legacy names last (byte order
+  stopped being report order at exactly the width the ordinal widens to: `1000-…` sorts before
+  `998-…`), each carrying `file`, `ordinal` (the leading three-or-more-digit ordinal,
+  `null` for a name written before the numbering, including the `YYYY-MM-DD-…` shape) and
+  `status` (`open` | `sent` | `fixed` | `superseded` | `unstated`, read as the first word of the
+  `- Status:` line in the report's HEADER FIELD BLOCK — the lines above the first `##` heading,
+  quoted code skipped in BOTH markdown spellings, fenced and indented, so a report quoting the
+  protocol's own template counts as whatever its own header says — and `fixed in 0.2.0-alpha.5`
+  counts as `fixed`). The
+  human view prints one row after `agents`:
+  `reports       loam-reports/ 12 · open 3 · sent 5 · fixed 3 · superseded 1 · next 013` — zero
+  counts omitted, the total always shown, `reports       (none)` when the directory is absent or
+  empty.
+- Reading it is best-effort and emits no finding: an unreadable file is an entry with status
+  `unstated`, an unreadable directory is `present: true` with `total: 0`, and a status word this
+  vocabulary does not know is `unstated` rather than a sixth bucket. No new code is emitted and
+  `doctor`'s `healthy` does not move for anything in the directory — an open report is not a
+  defect in the repository holding it. Reading stays local: nothing is transmitted, which is the
+  constraint the protocol is built around.
+- AGENTS.md's support paragraph now says reports are numbered and that `loam doctor` counts the
+  directory and says which ordinal is next.
+- What a repo notices: `loam doctor` prints a `reports` row it never printed before — `(none)`
+  on a repository that has never written one — and `loam doctor --json` carries a `reports` object
+  beside `agents`. Existing reports keep their names and are counted as `unstated` with no
+  ordinal until someone renames them and adds a `Status:` line; the next report an agent writes
+  lands as `loam-reports/001-…` in a directory of legacy names, because `next` is one past the
+  highest ordinal present and a `YYYY-MM-DD-…` name has none.
+
+### Added — the adopt brief on an edgeless landscape element
+
+- `loam adopt --service <id> --json` gains two additive keys under `landscape`: `landscape.touched`
+  — `true` when at least one edge in the `architecture/` project has an endpoint resolving to
+  the service (an intra-service edge counts: the predicate `loam context` prints as "(modelled, no
+  edges touch it)"), `null` whenever `landscape.modelled` is `null` or `false` — and
+  `landscape.attested`, the calls the service's own `model.likec4` declares across its boundary
+  (`direction`, `counterpartId`, `counterpart`, and `title` / `op` / `publishes` / `consumes` where
+  the edge carries them), sorted and de-duplicated, `[]` when the model is absent, does not parse,
+  or declares none, and read only in the edgeless state. `landscape.modelled` and
+  `landscape.elements` are now decided by the same element→service resolver `validate --all` grades
+  `landscape.service-unmodelled` on: a container titled like a sibling service, nested inside an
+  element bound to another service, resolves to its ancestor — so `loam adopt` reports such a
+  service `modelled: false` where it reported `true`, which is the answer the fleet run was already
+  giving.
+  `landscape.instruction` is no longer `null` on element existence alone: while an element resolves
+  to the service and no edge touches it, the brief names each attested call and asks for it as ONE
+  edge on the existing element, collapsed to the service and naming the other party as the map
+  already spells it — or, with nothing attested, points at the walk's outbound and message stops and
+  says draw NOTHING rather than invent an edge — and names the element's tags loam does not read (a
+  placeholder such as `#provisional`, and the view written `exclude element.tag = #<that>` that
+  keeps an adopted service hidden). The `architecture/landscape.likec4` target is back in that state
+  with `action: "edit"`, `required: true`, a shape refusing a second element and an edge-only
+  example. The text view prints the instruction under "what the fleet already says about this
+  service" and flags the row `EDGELESS` ("an element exists, no edge does") instead of `UNDRAWN`.
+  Until now `loam seed --from fleet.yaml` left every service absent from `calls:` as a bound,
+  edgeless element the brief then declared finished.
+- New `landscape.service-isolated` (warn, never gating, `--all` only, on the landscape target,
+  `subject` the service id): an element resolves to `services/<…>/<svc>/`, no edge anywhere in the
+  `architecture/` project touches it, and that service's `model.likec4` parses and declares at least
+  one call across its
+  boundary — the message names the first three. Evidence-gated on purpose: silent for a service with
+  no model (a seeded fleet), an unparseable model (`c4.invalid` owns it), a model reaching nothing,
+  an unmodelled service (`landscape.service-unmodelled` owns it), and a service the map already
+  touches with ONE edge while its model attests five — the check is touched/untouched, not a set
+  difference; `#external` elements are never
+  subjects. It suppresses `landscape.matched` like every finding. The brief's `checks[]`, the
+  `/loam-check` `--all` table and AGENTS.md's adopt step carry it; `/loam-adopt` step 5 states
+  the silent cases and points at `landscape.touched` in step 1.
+- One more statement in the adoption brief's unchecked list, now seventeen: whether an adopted
+  service is VISIBLE on the fleet map — a placeholder tag that survives adoption, a curated view
+  that lists its members by id, and `include *` collapsing to a boundary element
+  (`include <boundary>.**`). `/loam-adopt` step 3 names that housekeeping as part of the landscape
+  edit.
+- `loam adopt --service <id>` reads the fleet map as the `architecture/` PROJECT — the landscape
+  plus every other `.likec4` under `architecture/`, minus the generated `subsystems.likec4` — where
+  it read `architecture/landscape.likec4` alone. It is the document set `landscape.service-isolated`
+  already grades `touched` over, so `landscape.modelled`, `landscape.elements`, `landscape.inbound`,
+  `landscape.outbound`, `landscape.expects`, `landscape.touched`, `landscape.attested` and
+  `landscape.instruction` now answer about the same map `loam validate --all` does. What a repo
+  notices: a fleet that keeps a second `model { }` block, a use case or a palette in a sibling
+  `architecture/*.likec4` no longer gets a brief demanding edges it has already drawn —
+  `touched: true`, `instruction: null`, and no eighth `architecture/landscape.likec4` target — where
+  the fleet run on the same tree reported `landscape.matched`. The same widening makes
+  `landscape.parses` false, and `landscape.modelled` `null`, when any document under `architecture/`
+  fails to parse: the landscape file parsing on its own does not rescue a map the renderer cannot
+  load. No key added, no key removed. The edgeless instruction names the element's home as "the
+  fleet map (architecture/)" rather than a file it did not read — the WRITE still lands in
+  `architecture/landscape.likec4`, and the target's `path` says so.
+- The adopt brief's `model.likec4` example is headed with the service being adopted
+  (`// order-service's own C4 …`) instead of the literal `payment-service` it carried for every
+  service — one line above an `extend <fqn>` the brief already substituted, so the personalised half
+  taught an agent the rest of the header had been personalised too. `<svc>` joins `<fqn>` as a
+  placeholder the shape rules leave literal and `serviceBrief` fills in; the example never leaves
+  either in the payload.
+- What a repo notices: a drawn-but-edgeless service whose model reaches other systems gains one
+  `landscape.service-isolated` warning per service on its next `loam validate --all` — under
+  `--strict`, CI is red until an edge lands or the element is genuinely edgeless and stays so (a
+  model attesting no cross-boundary call is silent); a seeded service nobody listed under `calls:`
+  is briefed the edges instead of nothing.
+
+### Added — a home for an intra-service use case
+
+- A `dynamic view` over one service's own containers now has a slot loam reads and grades: any
+  `.likec4` beside `services/<…>/<svc>/model.likec4` (`usecases/<name>.likec4` by convention,
+  `views.likec4` read the same) or a tagged view inside model.likec4 itself — exactly the document
+  set the per-service renderer project registers, read whether or not `likec4.config.json` exists.
+  `loam validate --service <id>`, and `--all` per service, grade every view tagged
+  `#req-<Requirement-ID>` with the codes the fleet target already uses: `usecase.step-unbacked`
+  (error), `usecase.step-contested` (warn), `usecase.requirement-unresolved` (error — resolved
+  against THIS service's spec.md and arch.spec.md ids, four arms), `usecase.capability-unresolved`
+  (error — a `#cap-` tag beside a model is refused by placement, vocabulary or not) and
+  `usecase.flow-invalid` (error — a sibling that breaks the service project; model.likec4 keeps
+  grading alone, never `c4.invalid`). Untagged views are never graded, and an untagged sibling is
+  not even loaded while no view in the project opts in and no sibling mentions either reserved
+  prefix anywhere in its bytes; once loaded — a tagged view inside model.likec4 itself, or `req-` /
+  `cap-` in a sibling's comment or title — a project that does not read is one
+  `usecase.flow-invalid` whether or not any view in it opted in. A resolved service-local `#req-`
+  feeds nothing else yet. The feature slot for such a flow is deferred (ROADMAP).
+- Every surface that names a code for a `#req-` tag declared TWICE — once in the map's
+  `specification` and once in a tags-only block beside the `extend` — now names the one loam
+  actually emits. SCHEMA.md, `/loam-adopt` step 3 and `loam instructions loam-codes` all said
+  `c4.fleet-project-invalid` (a warning); measured, the finding lands where the second declaration's
+  FILE is: `c4.invalid` — an error that gates, suspends the model's grading and cascades six
+  `covers.unknown` — when the tags-only block is inside model.likec4, and `usecase.flow-invalid`
+  when it is in a sibling. `c4.fleet-project-invalid` is the fleet-scope class one step out: two
+  SERVICES each declaring the same tag locally, which no per-service project can see. No behaviour
+  changed; an agent routing on the printed code was being sent to the wrong severity and the wrong
+  repair.
+- Two corrections to the shared step graders, at fleet altitude too: a hop whose two endpoints
+  resolve to ONE service is no longer backed by that service's internal edges on the service tier
+  (measured: every internal relationship was a candidate, so an unbacked hop between two containers
+  of one service graded attributed and could never earn `usecase.step-unbacked`); and
+  `usecase.step-unlinked` no longer fires when the caller resolves to the provider — a service owes
+  no operationId to itself, and that is the guard's whole scope: a hop from a service-local flow
+  into another service's element still warns, exactly as it does on the fleet map. What a repo
+  notices: a landscape that draws a service as containers with a tagged hop between two of them
+  loses a wrong `usecase.step-unlinked` warning and may gain a right `usecase.step-unbacked` error;
+  a service directory holding a tagged `dynamic view` beside its model starts being graded.
+- `loam diff` no longer counts a service as a consumer of its own operation, on either half of the
+  question. A landscape edge whose SOURCE and TARGET both resolve to the provider is the provider's
+  own internal call — the rule `usecase.step-unlinked` already states — and so is a use-case hop
+  whose two endpoints resolve to it; the edge half excluded nothing while the message half already
+  did, so the downgrade this list promised could not be observed in the configuration it described.
+  Both are excluded now, and it is: a removal whose only trace in the fleet is the provider calling
+  itself reports `diff.op-removed` (warn) and the run exits 0, where it reported
+  `diff.op-removed-consumed` (error, `breaking: true`, exit 1). A second service's edge naming the
+  operation is still `diff.op-removed-consumed`.
+- The adopt brief's `checks[]` gains six `--service` rows: the five above and
+  `usecase.step-unlinked`, which the service target reports for a hop into a sibling's stand-in, and
+  which `/loam-check`'s `--service` table now carries a row of its own for. The arch.spec.md shape
+  names the hop-sequence slot; AGENTS.md's layout paragraph names the slot itself
+  (`services/<…>/<svc>/usecases/*.likec4`) and the styling opt-in beside it.
+- `loam explain` answers the right scope for the eight codes only a feature run raises. A markdown
+  fix table ends at the first line that is not a `|` row, and nothing separated `/loam-check`'s
+  `--feature <FEAT-id>` rows from the `--service <id>` ones sitting above them, so
+  `capability.uncovered`, `capability.remove-requirement-realized`, `glossary.term-exists`,
+  `usecase.flow-exists`, `deployment.doc-exists`, `deployment.doc-invalid`,
+  `deployment.doc-reserved` and the feature/archive arm of `usecase.flow-invalid` all came back
+  `scope: "--service <id>"` — a service run can raise none of them. They now read
+  `--feature <FEAT-id>`. What a consumer notices: `entries[].scope` changes value for those eight
+  in `loam explain <code> --json` and in `loam explain --codes --json`; the meanings and the fixes
+  are unchanged, and no code was added or removed.
+
+### Changed — the generated subsystem views join the repository's styling
+
+Every view in the generated `architecture/subsystems.likec4` now carries `global style subsystems`
+— written after its `title` and `description`, before its `include`/`group` — exactly when the
+`architecture/` project (the landscape merged with every other `.likec4` under `architecture/` the
+root `exclude` does not cover — a `palette.likec4` beside the map counts, and one under an excluded
+path is loaded by nobody; the one
+load `loam subsystem sync`, `validate --all` and `archive` share) declares a global style with the
+id `subsystems`, in either form: `global { styleGroup subsystems { … } }` or
+`global { style subsystems … }`. loam reads only that the id is declared — a census of the keys of
+`$data.globals.styles` beside the view-id census in `core/c4/parsed/view-ids.ts` — and never what
+the group says (docs/DESIGN.md rule 26). Nothing is written otherwise, and the file is
+byte-identical to before. When the project declares style groups under other names only, one
+comment line between the header and `views {` names them and says none is `subsystems`; there is
+no single-group fallback, because a second group declared for a hand-drawn view would otherwise
+switch the generated views' styling off on a change that touched no subsystem. Styling therefore
+restales the generated file on two triggers, and `subsystem.views-stale`, `loam explain` and the
+fix tables name both: declaring or removing the group named `subsystems` changes whether the views
+carry the `global style subsystems` line, and declaring or removing a group under ANY OTHER name
+changes the disclosure comment. What a repo notices:
+a fleet that already declares a group named `subsystems` (or any group, for the disclosure line)
+sees one `subsystem.views-stale` on its next `validate --all`, cleared by one `loam subsystem sync`.
+`loam seed` renders the file from that same project — the landscape it is about to write, staged
+beside every other `architecture/` document — so a palette kept in a sibling such as
+`architecture/usecases/palette.likec4` is referenced by the seeded views and never a stale file
+straight after a seed. No new code, flag or `--json` key. `LoadedDoc` gains the additive field
+`globalStyles` (the sorted declared ids), produced alike by every loader and pinned by the three
+parity suites; seven tripwire assertions in `test/likec4-view-shape.test.ts` pin the parsed shape
+at likec4@1.59.2.
+
+### Changed — the fleet's consumer census reads the models, not the map alone
+
+- `landscape.datastore-private`, `landscape.datastore-shared` and `landscape.platform-candidate`
+  count a consumer that a service's own EXTENDING `model.likec4` attests — an outbound call at the
+  element or a descendant — beside the edges `architecture/` draws. Under the extending shape the
+  container-level call lives in the model and only the service-level twin reaches the map, so a
+  store whose consuming edges were all drawn in models had zero consumers and earned nothing at all,
+  and a store reached by three models plus one map edge was reported `landscape.datastore-private`
+  naming the single service the map happened to draw. Extending models only: their ids are the map's
+  fully-qualified ids, so the join is exact, while a standalone model's ids are its own file's and
+  are never matched to a landscape element. A model that does not parse, or cannot be read,
+  contributes nothing.
+- `landscape.datastore-shared` now fires for a NESTED store. A store sitting inside the element that
+  resolves to its owner — declared there on the map, or added by the owner's extending model — is
+  private by construction and silent at one consumer, and is graded at two: `subject` is the store's
+  title as before, and the message adds ` — <owner>'s own store, written as '<fqn>'` beside the
+  consuming services it names — the store's OWN id, since `<fqn>` IS the store and the earlier
+  "nested under" sent a reader looking for a containing element of that name. The message then
+  states the reversibility directionally: the two placements give the store the same id, but with a
+  second consumer the move is one-way — out of the `extend` block onto the map is always safe, and
+  back into it breaks every other consumer's edge.
+  Until now the
+  strongest coupling two services can have rendered perfectly and was graded nowhere, because the
+  census only ever looked at elements drawn at fleet level.
+- `landscape.datastore-private`'s remedy names the placement instead of a directory, and names it
+  for the consumer's own model SHAPE rather than assuming one. For an EXTENDING consumer it says to
+  write the store in that model's `extend <fqn> { … }` block, or inside `<fqn>` on the map when the
+  map draws that service's containers. For a consumer whose model STANDS ALONE — or that loam could
+  not read as extending — it says the map placement and offers the migration to the extending shape
+  as the other arm, because `extend <fqn>` in a standalone model resolves nothing (such a model is
+  parsed alone) and following the old sentence there turned a run with 0 errors into `c4.invalid`.
+  Either way it states what happens next: a second service
+  reaching the same data draws a container-level edge to `<fqn>.<name>` in its own model plus a
+  service-level edge on the map, and loam counts that consumer — so the state is
+  `landscape.datastore-shared`, never silence. It also states which of the two placements keeps that
+  door open: the edge resolves only against a store the MAP declares, because a per-service project
+  is `architecture/` plus one model. The old "or add the second consumer's edge" is gone as an equal
+  remedy and survives as "if another service reaches the same data today, draw its edge and this
+  becomes that warning now". It also states the measured reversibility with its condition — the two
+  placements give the store the same id, `<fqn>.<store>`, and with one consumer either move is free:
+  out of the `extend` block onto the map always is, and back into it while no other service's model
+  or map edge names the store (measured on `examples/docs`: moving `db` out of order-service's `extend`
+  block into `orderService` on the map left the model at 12 elements · 8 relationships, left
+  `Covers: marketplace.orderService.db` in its `arch.spec.md` resolving, and left checkout-web's
+  container-level edge to it resolving) — and it qualifies the "never silence" promise: a consumer
+  whose model stands alone is not counted, because its ids are its own file's, so its edge belongs
+  on the map.
+- `landscape.datastore-private` and `landscape.datastore-shared` never take an element that stands
+  for a `services/<id>/` as their subject, at ANY depth. The fleet-level half has always skipped
+  one (a datastore bound to a directory is the binding checks' subject); the NESTED half did not,
+  so a `database` carrying `metadata { service '<id>' }` and drawn inside another service's
+  element became a store "owned" by its own binding, and one more reader made it
+  `landscape.datastore-shared` — advising the team to give each service a private copy of a
+  service. Both halves and the model-declared store census now share one `standsForService`
+  predicate, handed down on the input record because a `fleet/map/` module may not import `fleet/`.
+- `landscape.invalid`'s message generalises its hint. It spoke about use-case flows alone, so an
+  author whose MODEL EDGE named a container was told to move a flow that does not exist. It now says
+  that an unresolved name an extending model declares — a use-case hop or an edge naming
+  `<service-fqn>.<container>` — renders for the renderer and resolves for nobody here, and that the
+  repair is to name the SERVICE on the map and the container in that service's own model.
+- `landscape.service-isolated` never takes an `#external` element as its subject. The claim rested
+  on "an `#external` element is not an enumerated service", which is false for an element carrying
+  the tag AND a `metadata { service '<id>' }` binding to a directory that exists: the input set had
+  no tag filter, so a foreign box answered for one of our services. The isolation input SET now
+  skips `#external`, matching `landscape.binding-duplicate` and
+  `landscape.binding-unknown`. `landscape.service-unmodelled` keeps the unfiltered set — the
+  directory IS drawn. The `touched` walk applies NO tag filter, deliberately: it answers a different
+  question — does the map draw any edge on this service — and LikeC4 puts a kind tag on every
+  element of the kind, so `element topic { #external }` (the idiom
+  `examples/docs/architecture/landscape.likec4` documents) made an edge drawn from a service's OWN
+  topic stop touching that service. The warning fired on a service the map demonstrably reaches
+  while `loam adopt` reported `touched: true` on the same tree; the walk is the brief's
+  `landscape.touched` predicate exactly, tag and all.
+
+### Changed — the renderer wiring, measured rather than assumed
+
+- `loam subsystem sync` now DELETES a `likec4.config.json` that sits beside a model which EXTENDS
+  the fleet map, in the same journaled commit as everything else it writes, and `--json` `projects`
+  gains `projects.removed` (POSIX paths relative to the docs root, sorted by path (not by service
+  id — the survey's own order); `[]` on a run that removed none)
+  beside `projects.created`. The text view prints one `removed <path>` line per file and one
+  sentence saying why. The note this corrects said such a nested project was registered EMPTY and
+  therefore harmless; measured on likec4 1.59.2 it CLAIMS the model — the workspace loads two
+  projects, the model is Invalid inside its own one (the map's kinds are not in there with it) and
+  `export json --project fleet` loses the service's containers wherever that nested project claims
+  the model (measured both ways at the 1.59.2 pin: it did on a seeded fleet, and did not on
+  `examples/docs`, where the root project kept the model — what happens in every state is that the
+  docs root stops being a one-project workspace and `likec4 validate .` refuses without
+  `--project`). A repo that migrated 56 models to
+  `extend` and ran one `sync` kept 56 stray files and 57 projects; it now keeps one. A leftover
+  beside a model that is GONE still stays — that one really is the team's, and a nested project
+  holding no `.likec4` is silently absent from the renderer's list. `service.likec4-config-stray`'s
+  message is rewritten to the measured consequence and now names a repair `sync` actually performs.
+  `projects.current` narrows with it: it counts the services owed a project file that already had
+  one, and a model that extends the map is owed none — so on the run that deletes the strays it
+  drops by exactly the length of `projects.removed`, and every run after that reports the same
+  number both spellings would have.
+- `loam subsystem sync` no longer rewrites the generated views file when the map cannot be read.
+  `action` gains the value `blocked`: with `architecture/` unreadable and
+  `architecture/subsystems.likec4` already present, the run writes nothing about that file, prints
+  the reason, and `--json` carries that action plus `blocked.reason` reading `landscape-invalid` —
+  exit 0, because `loam validate --all`'s `landscape.invalid` is the gating surface. Before this,
+  any load error rendered the tolerant shape: the file was rewritten down to title and description,
+  losing the `global style subsystems` line, every `include` and the boundary comment, while `sync`
+  reported `updated … 1 subsystem view(s)` and answered `current` ever after. The render also now
+  falls back to the landscape FILE when only a SIBLING document breaks the project, so a duplicate
+  `subsystems` group declared in two `architecture/` documents costs nothing. With no generated file
+  yet, and inside a tree-changing verb's commit window (`new`/`move`/`rm`/`rename`, whose contract is
+  that the file lands with the change), the tolerant shape is still written and the same one-line
+  note is printed.
+- The `architecture/` document set every reader shares now honours the root `likec4.config.json`'s
+  `exclude`. A `.likec4` under `architecture/` the renderer never loads is no longer loaded by loam
+  either: a palette under an excluded path used to yield a `global style subsystems` reference the
+  fleet project could not resolve — `likec4 validate` Invalid on every run while `loam validate
+  --all` reported 0 errors, `doctor` was healthy and `sync` said "current" — and a broken excluded
+  document blanked the whole map. A root config loam cannot read an `exclude` list out of filters
+  nothing.
+- An `exclude` entry is now read the way the renderer reads it, measured rather than reasoned about.
+  loam interpreted only a literal `/**` suffix, so a root config written `services/**/*`,
+  `services/*`, `services/` or the bare `services/<tree>` hid every extending model with zero
+  findings; the first repair of that read the entry as a walk over path SEGMENTS, which is not what
+  LikeC4 does either. Measured at the 1.59.2 pin on a scratch fleet of five documents, by putting
+  one entry in the root config and counting the "N files" `npx likec4 validate .` reports: a bare
+  entry is a raw PREFIX with no end anchor (`services/pay` -> 3 files, hiding BOTH
+  `services/payment-service` and `services/payments/payment-service`; `architect` -> 3, hiding all of
+  `architecture/`), it must start on a `/` boundary (`ervices` and `ces/payment-service` -> 5, that
+  is, nothing), `*` stays inside one segment while `**` crosses (`architecture/*.likec4` -> 4, so
+  the nested use case survives; `*.likec4` -> 0), and a glob form does NOT prefix-match
+  (`services/pay/**` -> 5). LikeC4 prefixes an entry that does not begin with a doubled star with
+  one, joins it onto the project folder and matches with picomatch `contains: true` — the missing
+  end anchor is that option. So `service.model-excluded` fires now, naming the entry verbatim, on
+  every spelling including a starred middle segment; `service.model-unexcluded` no longer
+  false-positives on a standalone model whose directory such an entry already covers; and
+  `subsystem sync` takes back an entry that hides an extending model whatever its spelling — the
+  write side asked "which directory does this entry name", which answers nothing for a starred
+  segment, so `services/*/svc-b` hid a model forever while `service.model-excluded` named that same
+  command as the repair — and appends nothing for a directory the surviving list already covers.
+- The root `exclude` filter on the `architecture/` document set now has a floor:
+  `architecture/landscape.likec4` stays in the set whatever the list says. Without one, an entry a
+  team writes for a palette (`architecture/*.likec4` covers both) left the architecture project
+  holding ZERO documents — and an empty project parses with zero errors, so every reader took it for
+  "the map declares nothing". On a seeded two-service fleet that produced four errors, all false:
+  `landscape.service-unmodelled` twice, naming the very file that models both services and telling
+  the reader to add an element already in it, plus `c4.invalid` on the extending model; and
+  `loam subsystem sync` answered `updated` and rewrote a good generated file down to a title, with
+  no line in either run mentioning the `exclude` entry that caused it. loam now grades one document
+  the renderer may skip rather than asserting a fleet's whole architecture says nothing.
+- `loam subsystem sync` answers `blocked` whenever the `architecture/` PROJECT does not parse, not
+  only when `architecture/landscape.likec4` itself is unreadable. The landscape-file fallback that
+  saves the element join says nothing about the STYLE CENSUS — a palette may live in any `.likec4`
+  under `architecture/` — so a run made while an unrelated sibling was broken reported `updated`,
+  deleted the `global style subsystems` line from a good generated file, answered `current` ever
+  after, and never earned `subsystem.views-stale` while the map stayed invalid. The file is now left
+  byte-identical in that state and the note names what was unavailable.
+- `loam subsystem sync --json` carries `projects.exclude.unreadable` (boolean, emitted on every
+  run). `entries: []` alone collapsed the two answers loam insists must stay apart: "the root
+  project excludes nothing" and "loam could not read an `exclude` list out of the root file". The
+  text view has always had a note for the second; a machine consumer reading `entries: []` got the
+  opposite of the truth about what the renderer will load. Additive, beside `projects.exclude.removed`.
+- `loam subsystem sync`'s "— nothing to write." tail is dropped when the run rewrote the root
+  `likec4.config.json`'s `exclude`. It counted only the per-service project files created and
+  removed, so a run with a current views file printed "nothing to write." immediately above the line
+  reporting the rewrite.
+- `c4.fleet-project-invalid` now enumerates what the renderer actually loads. The document set is a
+  walk of the docs root — everything the root `exclude` leaves, minus the generated
+  `architecture/subsystems.likec4`, minus every standalone service directory (owned by
+  `service.model-unexcluded`), minus `features/` (a delta carries its own `specification` and the
+  directory is transient). A `.likec4` in a SUBSYSTEM directory — the parent of service directories
+  — was in none of the three roots the check used to merge: `validate --all` came back
+  byte-identical to baseline and never named the file while `npx likec4 validate --project fleet .`
+  reported Invalid over the same tree. The finding also gains `locations` (the file the error is IN,
+  not `architecture/landscape.likec4` on every one of them) and `details`, and its tail now names
+  the failure it actually is — a double declaration, an unresolved reference, or neither — instead
+  of always blaming a double declaration.
+- Every LikeC4 line number loam prints is 1-based, the way an editor counts — and deliberately NOT
+  the way `likec4 validate` prints it, which passes the LSP range's start line through and so says
+  `Line 8` for a fault on line 9.
+  `c4.invalid`'s details said `L3` for an error on line 4; `c4.fleet-project-invalid` printed
+  `model.likec4:0` for a declaration on line 1; and the feature arm of `usecase.flow-invalid`
+  printed no line at all and an ABSOLUTE Windows path into loam's own staging tree — it now spells
+  the authored file docs-relative with forward slashes and an `L<n>`, exactly as the service arm of
+  the same code does, in the text view, in `--json` and in the `loam archive` block message.
+
+### Fixed — the adoption brief answers off the document it actually read
+
+- `loam adopt` no longer briefs a write to the shared fleet map when the map could not be READ.
+  The eighth target (`architecture/landscape.likec4`) is emitted on `landscape.modelled === false`
+  — a read that succeeded and found nothing — and on the edgeless state; `modelled: null` ("loam
+  could not read the map", which since the `architecture/`-project widening includes a broken
+  palette or use case beside a landscape that parses perfectly) now emits no target at all.
+  It used to fall through the same gate as "the map draws nothing for this service", so the brief
+  handed an agent the UNDRAWN block — "add one top-level element bound to its directory" — for a
+  service the map already declares and binds, and splicing it earned `landscape.binding-duplicate`.
+  `landscape.instruction` carries the whole answer instead and names the documents that failed.
+- `loam adopt`'s fleet-map instruction and the text view's landscape headline no longer name
+  `architecture/landscape.likec4` as the broken file when the document that failed is a SIBLING
+  under `architecture/`. The instruction now names the failing documents docs-relative with their
+  error count — the same spelling `validate --all`'s `landscape.invalid` prints — and the headline
+  says `The fleet map (architecture/) does not parse — fix that first; the files are named below.`
+  The brief and the fleet run on the same tree used to blame two different files.
+- `loam adopt` no longer marks `openapi.yaml` required because a document beside the fleet map
+  broke. The API question is answered off the landscape FILE (`landscape.callersKnown`, added to
+  `--json`: true when the `architecture/` project parses, and true when it does not but the
+  landscape file does), which is the evidence `loam list` and `loam context` already read: a broken
+  `architecture/palette.likec4` used to flip `openapi.yaml` from `create missing` to
+  `create MISSING` for a browser UI the map proves nobody calls, and told the agent to write an API
+  contract for it. With the landscape file itself unreadable the contract is still owed.
+- `loam adopt`'s model.likec4 example prints a short `<your-element-id>` where loam has no id to
+  substitute, and carries the reason once as a `//` comment above the block. The placeholder used
+  to be a 103-character English sentence spliced into all three code positions `<fqn>` occupies —
+  the `extend` line, the source of a container edge and `view of` — on the command's most common
+  invocation, a brand-new adoption.
+- `loam adopt`'s arch.spec.md shape rule named `c4.fleet-project-invalid` (warn, `--all`) for a
+  `#req-` tag declared both in the map and beside the model. Measured, that is `c4.invalid` (error,
+  and the model's grading is suspended behind it) when the tags-only block is in model.likec4 and
+  `usecase.flow-invalid` when it is in a sibling; `c4.fleet-project-invalid` is the fleet-scope
+  class one step out, two SERVICES each declaring the same tag locally. The rule now says so, and
+  matches the same statement in SCHEMA.md.
+- `loam adopt`'s model.likec4 shape rule for `c4.element-unowned` leads with the nested remedy —
+  a store or component this service OWNS goes INSIDE the `extend <fqn> { }` block, where its id
+  becomes `<fqn>.<name>` — before the two existing arms, matching the `--service` fix table and
+  SCHEMA's grades table.
+- `loam adopt`'s `landscape.invalid` check description said "architecture/landscape.likec4 exists
+  but does not parse". It now says the `architecture/` PROJECT does not parse — the landscape or
+  any `.likec4` beside it — and that the message names the document that broke.
+
+### Fixed — one tree, one answer: the gate's preview, and the map's other readers
+
+- The merge preview every feature-side gate reads is now routed exactly as `loam archive` routes:
+  the fleet's extending models reach it, so an addition the delta nests inside a service is
+  previewed in that service's `model.likec4` and not on the map. Without them the preview held
+  interior the archive puts somewhere else, and `usecase.flow-invalid` — the gate `--approve`
+  cannot override — failed open on the one shape it exists for. Measured on a copy of
+  `examples/docs`: a feature nesting `cache` under `marketplace.orderService` and hopping
+  `checkoutWeb -> marketplace.orderService.cache` from `features/<FEAT>/usecases/` passed
+  `validate --feature`, archived at exit 0, and left a fleet whose next `validate --all` reported 7
+  errors — one `landscape.invalid` plus one `spine.landscape-invalid` per service — against a file
+  its author never wrote. The gate now refuses before anything is written, `validate --feature`
+  gives the same verdict, and a flow hopping between elements the map itself draws still archives.
+  `deployment.doc-invalid` is wired the same way and had the same hole.
+- `loam context <service>` reads the fleet map as the `architecture/` PROJECT — the landscape
+  merged with every use case, palette and second `model { }` block beside it — never
+  `architecture/landscape.likec4` alone. Two commands answered opposite things about one tree:
+  measured on a two-service fleet with a broken `architecture/palette.likec4` beside a landscape
+  that parses, `loam adopt --service order-service` reported `parses: false` and refused to say
+  anything about the map, while `loam context order-service` reported `parses: true`,
+  `modelled: true` and listed the map's edges — and an agent handed both has no way to tell which is
+  right. `landscape.present` is still a fact about the FILE; `landscape.parses` is now a fact about
+  the project the renderer loads, so a broken sibling reads here as "nobody could look", the answer
+  `validate --all` and `adopt` already gave. The second load of that same project the deployment
+  slice used to make when the landscape file declared no `deployment { }` block is gone with it: one
+  parse, one answer.
+- `loam seed` computes the generated views file's style census from the `architecture/` documents
+  the root `likec4.config.json`'s `exclude` leaves, not from a raw walk of the directory. A
+  `palette.likec4` under an excluded path is loaded by neither the renderer nor `validate --all`,
+  yet seed read it and wrote `global style subsystems` into `architecture/subsystems.likec4` — a
+  name the fleet project cannot resolve, written by the command whose own `next` line is
+  `loam validate --all`. The same defect one command over from the one the exclude filter fixed in
+  the loader. The fleet use-case scan's cheap tag gate was corrected with it: it walked
+  `architecture/` for itself, which could only over-scan (it is a prefilter before a load that does
+  apply the exclude), but two lists that disagree about what the project is are two answers waiting
+  to drift.
+- `landscape.invalid`'s head reads `<documents> have N error(s)` once more than one document broke,
+  matching `spine.landscape-invalid`. The named list is comma-joined when the `architecture/`
+  project has errors in two files, and the fleet line said "a, b has 4 error(s)" directly above the
+  service line saying "a, b have 4 error(s)" about the same two files — one report, two spellings of
+  one fact.
+
+### Fixed — a second verification round: what the archive routes, and what every message names
+
+- `loam archive` no longer refuses a delta written in the legacy title-join spelling inside a group
+  the map declares. Routing an addition into a service's extending model now requires the delta to
+  spell the whole parent chain in the MAP's own ids — a living element, a container an extending
+  model already declares, or a declaration this same delta adds — instead of only requiring that
+  *some* ancestor be living. A grouped map (`marketplace = group { … }`, the shape
+  `loam init --example` ships) made the old guard pass on `marketplace.orderSvc`, the addition was
+  written as `extend marketplace.orderSvc` — an id the map has never declared — and the model's
+  parse net refused the whole archive with `merge-failed` and nothing written. What a repo notices:
+  such a delta merges onto `architecture/landscape.likec4` under the map's own id and exits 0 again,
+  exactly as it does when the service's model is standalone or absent. The documented remainder is
+  unchanged: a title-joined parent keeps the map path.
+- A service a feature INTRODUCES now keeps its interior out of the fleet map when its directory
+  already holds an extending model. The new element's containers arrive inside its authored bytes and
+  carry no feature tag of their own — LikeC4 does not inherit tags, so nothing in the addition set
+  could see them — and they rode onto the map: `loam adopt --service <svc>` then told the team to
+  write the same container into `extend <fqn> { }`, and the renderer reported a duplicate element
+  blamed on both files while the service graded `c4.invalid`. Now the box lands on the map without
+  its interior, the children are spliced into the model's `extend <fqn> { }` block (created if
+  absent), and `loam archive` prints the second
+  `architecture: merged into services/<…>/model.likec4` line for it. A service arriving with no
+  directory at all, and one whose block also draws an internal edge between its own containers, keep
+  the previous behaviour byte for byte — an edge written inside the block names its endpoints by
+  their local names and there is no legal split, so the block rides whole. That is ONE decision and it covers the whole block: a child or an edge
+  the delta tags with the feature rides with a block that rides and is spliced with a block that
+  splits, never placed twice. While the two were decided separately the tagged child landed in both
+  documents and the merge refused itself, `merge-failed`, on a delta neither half was wrong about.
+- Both C4 merges now splice with the target document's own line endings. A CRLF
+  `architecture/landscape.likec4` or `services/<…>/model.likec4` came back with a handful of bare-LF
+  lines in the spliced region, and a CRLF delta's blank lines arrived carrying the target indent as
+  trailing whitespace. A document with one convention keeps it; a document that is already mixed is
+  left alone, because there is no convention to match.
+- `landscape.datastore-shared` and `landscape.datastore-private` now state the reversibility of a
+  private store's placement **directionally**, because the unconditional clause was false in every
+  state `datastore-shared` prints in. The two placements do give the store the same id
+  (`<owner-fqn>.<store>`), but the move is only free one way: out of the owner's `extend` block onto
+  the owner's element on the map is always safe, and back INTO the `extend` block breaks every other
+  consumer's edge — `c4.invalid` on that service's model, or `landscape.invalid` when the edge is
+  drawn on the map — because a per-service project is `architecture/` plus one model, so an `extend`
+  block is visible to its own service's project alone. `datastore-shared` needs a second consumer to
+  fire, so the state it prints in is exactly the state in which map→extend breaks; `datastore-private`
+  has one consumer, so it says both moves are free *today* and names the condition that ends that.
+- `landscape.datastore-private`'s no-model arm offers a model to WRITE, not one to migrate: with no
+  `model.likec4` at all it now says "write an extending model at `<path>`" one sentence after saying
+  loam read no extending model there. The STANDALONE arm still says "migrate the model", which is
+  correct for it.
+- `landscape.service-isolated`'s message names the fleet map rather than one file: "no edge in the
+  fleet map (architecture/) touches it". The check's input is the `architecture/` PROJECT — an edge
+  added to `architecture/extra.likec4` and never to `landscape.likec4` silences it, measured — so the
+  message now agrees with SCHEMA, with `loam explain landscape.service-isolated` and with the adopt
+  brief, all three of which already said "anywhere in `architecture/`".
+- `loam doctor` prints LikeC4 line numbers 1-based, through the same `errorText` helper every other
+  surface uses. `doctor.landscape-invalid` hand-rolled its own `(line <n>)` spelling and passed the
+  LSP range through raw, so it named the line above the fault and disagreed with `validate --all`
+  about one error on one tree. The message now reads
+  `architecture/landscape.likec4 does not parse: L<n>: <message> — and N more`.
+- `loam context --json` and `loam explore --json` gain `landscape.broken`: the `architecture/`
+  documents that failed, docs-relative POSIX, deduped and sorted, `[]` while `landscape.parses` is
+  true. Spelled exactly as `landscape.invalid` and the adopt brief spell them, so the three surfaces
+  name one file one way. Both commands read the `architecture/` PROJECT, so the document at fault is
+  very often a sibling beside a landscape that reads perfectly.
+- The adopt brief no longer promises a warning that cannot fire. On an element carrying `#external`,
+  the edgeless instruction and the `landscape.likec4` target's shape rule say that
+  `landscape.service-isolated` will NOT fire (the check removes every `#external` element from its
+  subject set), that this brief is the only place the state is named, and that dropping `#external`
+  makes the check apply again. Every other tree keeps the previous sentence.
+- The adopt brief's `checks[]` row for `c4.declaration-diverged` names "the fleet map
+  (`architecture/`)" instead of `architecture/landscape.likec4`. The map is a project; LikeC4 hands
+  back no source document for an element, and the finding's own message and `loam explain` already
+  refused to name a file.
+- `loam adopt --json`'s `landscape.inbound`/`landscape.outbound` drop an edge whose two endpoints
+  resolve to the SAME service — a service's own internal wiring drawn on the map made it its own
+  caller. `landscape.touched` is unchanged: it is now read off the map's relationships rather than
+  off those two lists, so it still counts an intra-service edge and still matches
+  `landscape.service-isolated`'s predicate exactly.
+- The service arm's use-case findings (`usecase.step-unbacked`, `usecase.step-unlinked`,
+  `usecase.requirement-unresolved`, `usecase.capability-unresolved`) carry the flow FILE as
+  `locations[0]` with role `primary` and the service directory beside it as `scope`. They carried the
+  service directory alone, so a `--json` consumer had to parse the prose to learn which `.likec4` to
+  open. `usecase.flow-invalid` on the same arm already named its file.
+- `usecase.flow-invalid`'s undeclared-tag hint tells a `cap-` author the placement rule instead of a
+  declaration that cannot help: a capability is claimed at fleet altitude, so declaring `tag cap-…`
+  beside a model makes the file parse and earns `usecase.capability-unresolved` on the next run. The
+  `req-` hint is unchanged.
+- The services tree walk never classifies a service's own reserved subdirectory (`adrs`, `usecases`,
+  `ui` — SCHEMA's service layout) as a service or a subsystem. Writing the documented
+  `services/<id>/usecases/<name>.likec4` slot into a directory holding no artifact FILE used to make
+  the walk read `usecases` as a service and its parent as an unmarked group: three errors
+  (`subsystem.unmarked`, `landscape.service-unmodelled` for `services/<id>/usecases/`,
+  `landscape.binding-unknown` for the real service) earned by following the instruction `loam init`
+  had just scaffolded. Such a directory is also not counted when deciding whether a directory is a
+  group, so a real service filed beside a reserved slot still refuses with `subsystem.unmarked` and
+  is still named.
+- `loam` now strips a leading UTF-8 byte-order mark before parsing the root `likec4.config.json`.
+  PowerShell's `Out-File` writes one by default, so a Windows shell saving the file loam itself wrote
+  left every `exclude` grade silent while the renderer went on applying the list (measured:
+  `npx likec4 validate .` at 3 source files of 8 with `services/**` in force, `loam validate --all`
+  at 0 errors and `doctor` healthy). A rewrite through `loam subsystem sync` drops the mark.
+- `service.model-excluded` asks the FILE question too. An `exclude` entry shaped like a file
+  (`services/**/model.likec4`, `**/model.likec4`) hides a model as thoroughly as one naming its
+  directory, and nothing said so: on `examples/docs` such a line took the renderer to 3 source files
+  of 8 while `loam validate --all` printed the string "exclude" not once. It is reported now, with
+  the repair that fits it — `loam subsystem sync` maintains only the `services/` directory entries,
+  so the file shape has to be narrowed or deleted by hand, and the message says which shape you have.
+- `loam seed` no longer overwrites a hand edit written ABOVE the scaffold's landscape stub.
+  `isLandscapeStub` matched with `endsWith`, so anything a person put before the stub was invisible
+  to the guard: a two-line "OWNED BY THE ARCHITECTURE GUILD — do not regenerate" header was replaced
+  without a word while seed printed "replaced the scaffold's untouched stub", against its own refusal
+  text ("Seed never overwrites human work"). The suffix match existed for exactly one prefix — the
+  comment preamble `migrate-openspec` stages above the identical stub, closed by a bare `//` line —
+  so that is now the only prefix accepted, at every scaffold generation. What a repo notices:
+  `loam seed` refuses with `seed-landscape-edited` and writes nothing, and `loam status` calls such a
+  map `authored` rather than `stub`. A repo staged by `migrate-openspec` still seeds.
+- `loam doctor` counts the report corpus that is there when the config is the thing that is broken.
+  Read from a SUBDIRECTORY of a repo whose `loam.json` does not parse, it used to report
+  `total 0, next 001` while naming the broken config's own path in the same envelope — handing out an
+  ordinal five existing reports already used. `doctor` is the preflight that runs precisely when the
+  config may not resolve, so `reports.dir` now resolves beside the `loam.json` it FOUND.
+- `/loam-check`'s `c4.fleet-project-invalid` row spells the `details` format the finding emits:
+  `<path>: L<n>: <error>`, with the colon after the path that the message's own head has always
+  carried. The row promised `<path> L<n>: <error>`, so an agent splitting on the documented separator
+  split in the wrong place.
+
+## [0.2.0-alpha.5] - 2026-09-03
+
+An adopted service's model renders from the docs root. Still a prerelease on the `alpha` line:
+`npm i @ybotok/loam@alpha` installs it. Nothing below is breaking. What a repo with adopted services
+NOTICES: one `service.likec4-config-missing` warning per service on its first `validate --all`
+until one `loam subsystem sync`, and from that sync on `--project` for `likec4 validate` at the
+docs root.
+
+### Added — an adopted service's model renders from the docs root
+
+The root `likec4.config.json` excludes `services/**`, and has to; what that cost was never stated:
+an adopted service's `model.likec4` — the artifact `loam adopt` spends the most effort on — was a
+box on the fleet map with nothing renderable inside it in the renderer opened at the docs root, and
+the only documented way to see its containers was one `npx likec4 start services/<id>` per service.
+One problem report; one file per service closes it.
+
+- `loam subsystem sync` now writes `services/<…>/<svc>/likec4.config.json` beside every service
+  `model.likec4` that has none, whenever the root `likec4.config.json` exists — **create-only**: a
+  file that exists is yours and is never compared, rewritten or removed. Measured at the pinned
+  likec4, a project file inside a service directory registers the model as a project of its own
+  regardless of the root's exclusion, so `npx likec4 start` at the docs root shows `fleet` plus one
+  project per service. Without the root file nothing is written and the text says `loam doctor`
+  prints it. `subsystem sync --json` carries an additive `projects` key, `{ root, created, current }`
+  — whether the root file exists, the repo-relative paths written this run (sorted by id), and how
+  many model-bearing services already had one. `action` still describes
+  `architecture/subsystems.likec4` alone.
+- `loam validate --all` gains one warning per service, `service.likec4-config-missing`, on the
+  `landscape` target with the service's tree path as its `scope`: `model.likec4` exists and the
+  project file does not. Never an error, never gating, never in `--service`, `status` or `doctor`;
+  the fix is `loam subsystem sync`, never a hand-written file. `doctor.likec4-config-missing`'s fix
+  text now hands over to `sync` once the root file is written.
+- The project name: the id with every `.` folded to `-` (LikeC4's name grammar refuses the byte),
+  prefixed `service-` when that would equal the root project's `fleet` or LikeC4's reserved
+  `default`; `title` is the id verbatim, and the title is what the renderer's picker shows. Not
+  injective — an id spelled billing.core beside one spelled billing-core, or `service-fleet` beside
+  `fleet` — and LikeC4 suffixes the later one `-1`; disclosed, never graded.
+
+What a repo NOTICES on upgrade: one warning per adopted service on the first `validate --all` until
+one `loam subsystem sync` — under `--strict`, CI is red until then; after that `sync`, N untracked
+files (`sync` does not `git add` them) and `move-uncommitted` on the next `loam subsystem move` of
+such a service until they are committed; from the first `sync` on, `likec4 validate` at the docs
+root needs `--project <name>` (measured: with more than one project it refuses bare, while
+`likec4 build` and `likec4 export` take every project and need no flag); and the renderer's project
+list grows by one per adopted service, beside `fleet`. No command, flag, exit code or envelope key
+changes; `projects` is additive.
+
+## [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. **Not published (noted 2026-10-10):** the `v0.2.0-alpha.3`
+tag was cut, but it was withdrawn before its publish step — the `0.2.0-alpha.4` section above says
+so, and that release carries everything here — so `npm i @ybotok/loam@alpha` never installed this
+version, and `npm view @ybotok/loam dist-tags` is the record of what does. 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