@ybotok/loam 0.2.0-alpha.7 → 0.2.0-alpha.9

package/CHANGELOG.md

@@ -10,6 +10,1317 @@ 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.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
@@ -1150,7 +2461,10 @@ now rewrites the bytes of every view beneath it.
 ## [0.2.0-alpha.3] - 2026-09-03
 
 The generated subsystem views, made readable — and the defect that hunt found underneath them.
-Still a prerelease on the `alpha` line: `npm i @ybotok/loam@alpha` installs it. Nothing below is
+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`.