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

package/dist/core/agent/workflows/check.js

@@ -77,7 +77,7 @@ and say it.
 | \`spec.requirement-id-invalid\` | a \`Requirement-ID\` violates \`[A-Za-z][A-Za-z0-9._-]{0,127}\` | replace it with a portable stable ID; do not remove an established ID merely to silence the check |
 | \`spec.requirement-id-repeated\` | one requirement declares \`Requirement-ID\` more than once | keep exactly one identity line |
 | \`spec.requirement-id-duplicate\` | one ID identifies multiple requirements in the same file | give each requirement its own stable ID |
-| \`openapi.generated-stale\` (warn) | \`loam.json\` names \`contracts.openapi\` — where this repo's BUILD writes its contract — and that document differs from the committed \`services/<id>/openapi.yaml\`. The docs-repo copy is what every operation join is graded against, so the fleet is being checked against a contract the service no longer serves. Compared by a digest over canonical JSON, so key order and formatting never fire it. Service-repo only; silent with no \`contracts\` block | review the difference and copy the generated document across — loam never writes it for you, because the committed contract is one somebody agreed to, not a cache of the build |
+| \`openapi.generated-stale\` (warn) | \`loam.json\` names \`contracts.openapi\` — where this repo's BUILD writes its contract — and that document differs from the committed \`services/<id>/openapi.yaml\`. The docs-repo copy is what every operation join is graded against, so the fleet is being checked against a contract the service no longer serves. Compared by a digest over canonical JSON, so key order and formatting never fire it. The \`details\` name the operationIds that differ — served but not in the committed copy, committed but no longer served — and the message says when the sets agree, so a reworded description reads apart from vanished endpoints. Service-repo only; silent with no \`contracts\` block | review the difference and copy the generated document across — loam never writes it for you, because the committed contract is one somebody agreed to, not a cache of the build |
 | \`contracts.source-missing\` (error) | \`contracts.openapi\` names a path and nothing is there — usually CI validating before it builds | run the build first, or correct the path |
 | \`contracts.source-invalid\` (error) | \`contracts.openapi\` resolves outside the repository, or names a file that does not parse as YAML or JSON | correct the path, or fix the document the build emitted |
 | \`spec.unknown-directive\` (warn) | a requirement body line whose key is one or two edits from a directive and is not one — \`Realises:\`, \`Capabilties:\`, \`Opertaions:\`. This is the one case where the corpus is quieter than it looks: an unrecognised key is prose, so the join it resembles simply does not exist and every check over it stays green for want of anything to fail. Measured by edit distance, not by prefix, so ordinary prose keys (\`Note:\`, \`Context:\`, \`Owner:\`) do not fire it; fenced blocks and table cells are skipped, because a directive spelling inside an example is a sample value | correct the spelling, or reword the line so it does not read as a directive |
@@ -94,7 +94,7 @@ and say it.
 | \`openapi.ref-unresolved\` (warn here; error at archive plan time) | internal \`$ref\`(s) in the living contract that resolve to nothing in the document — the operation validates while its schema is silently absent. External refs (not starting \`#/\`) are never checked | define the missing component or fix the pointer the \`details\` name |
 | \`openapi.baseline-stale\` | the living operation — or a pinned path-level key or component — changed after this delta edited it | somebody landed a change to it in between. Re-read the living value, fold in what you still mean, then \`loam rebase <FEAT>\` |
 | \`openapi.baseline-missing\` (warn, gates archive; one per service) | operations, path-level keys or components in this feature's openapi.yaml carry no baseline (\`x-loam-based-on\` / \`x-loam-baselines\`) | run \`loam rebase <FEAT>\`. Until you do, archive refuses: the merge cannot tell the surfaces you EDITED from the ones you merely restated, so it would upsert all of them — and every restated one reverts whatever landed on it. \`--approve\` merges unpinned deliberately |
-| \`openapi.baseline-invalid\` | an \`x-loam-based-on\` that is not a digest, one on an operation the living contract has no slot for, a malformed \`x-loam-baselines\` record, or a record entry naming a surface the delta does not restate (or whose living value is gone) | \`loam rebase\` writes both; a new value has no living version to be based on, so it carries no entry |
+| \`openapi.baseline-invalid\` | an \`x-loam-based-on\` that is not a digest, one on an operation the living contract has no slot for, a malformed \`x-loam-baselines\` record, or a record entry naming a surface the delta does not restate (or whose living value is gone) | \`loam rebase\` writes both; a new value has no living version to be based on, so it carries no entry. A pinned operation whose living one a parallel feature has since REMOVED lands here too, and \`openapi.op-revived\` fires beside it — the pinned quote reports both: re-read the living contract and delete the whole operation from the delta — dropping only the pin clears this one and leaves \`openapi.op-revived\`, because unpinned it reads as an addition. Keep it only if this feature deliberately brings the operation back: then drop the pin and archive with \`--approve\` past \`openapi.op-revived\`. One a parallel feature MOVED to another slot (or retired here, before another re-added it elsewhere) lands here as well, and the message names where it lives now: delete the quote and make any change there — archiving past it while it still lives there would answer the operationId at both addresses; to move it back on purpose, drop the pin and add a removal marker at that address, or define another operation there. If you edited it, settle with that feature first |
 | \`spec-api.op-undefined\` | a LIVING requirement's \`Operations:\` line names an operationId this service's openapi.yaml does not define (the same code fires inside a feature delta) | define the endpoint, or correct the \`Operations:\` line — the two axes disagree about what the service exposes |
 | \`api.ungoverned\` (warn) | operation(s) no requirement's \`Operations:\` line names | write the requirement, or link an existing one |
 | \`api.ops-unlinked\` (warn) | operations AND requirements exist but zero \`Operations:\` lines join them — the API axis is vacuously green | link each requirement to the operations it governs |
@@ -104,7 +104,7 @@ and say it.
 | \`spine.op-link-missing\` (warn) | a landscape "Calls" edge into this service with no \`metadata { op }\` | link it to the operationId |
 | \`spine.op-deprecated\` (warn) | a landscape edge calls an operation this service's OpenAPI marks \`deprecated: true\` — the consumer is standing on a contract being retired | migrate the consumer to the replacement operation; deprecation is the first step of retiring an op, and the op stays defined until a human removes it |
 | \`service.no-asyncapi\` | no asyncapi.yaml, and message link(s) already point into it — a landscape edge's \`metadata { publishes }\` / \`metadata { consumes }\`, or a LIVING requirement's \`Publishes:\` / \`Consumes:\` line. The \`details\` list the stranded message names. Silent when nothing joins into it: an async contract is optional, and most services touch no topic | put the file back — every link the \`details\` name resolves to nothing until it is there |
-| \`asyncapi.invalid\` | asyncapi.yaml exists but does not parse — an unreadable contract proves nothing, so no \`event.*\` or message-spine finding is graded against it. The same code fires for a FEATURE's own asyncapi.yaml under \`--feature\`, where it gates the archive and suspends the service's event-axis checks the same way | fix the YAML first — the event axis is unchecked until it reads |
+| \`asyncapi.invalid\` | asyncapi.yaml exists but does not read as AsyncAPI 3.0: it does not parse, or its \`asyncapi:\` field says 1.x or 2.x (whose \`publish\`/\`subscribe\` loam does not read — the \`details\` name the version). An unreadable contract proves nothing, so no \`event.*\` or message-spine finding is graded against it. The same code fires for a FEATURE's own asyncapi.yaml under \`--feature\`, where it gates the archive and suspends the service's event-axis checks the same way | fix the YAML first, or upgrade an older document with \`asyncapi convert --target-version=3.0.0\` (the AsyncAPI CLI) — the event axis is unchecked until it reads |
 | \`asyncapi.remove-marker-living\` | a living asyncapi.yaml carries feature-only \`x-loam-remove: true\` — at a \`channels.<key>\` / \`operations.<key>\` / \`components.messages.<key>\` slot, or nested on an inline channel message | remove the marker from the living contract; retire a slot through a feature delta's asyncapi.yaml instead |
 | \`asyncapi.duplicate-message\` (warn) | one message name is declared in two slots — every join on the name (an edge's \`metadata { publishes }\`, a requirement's \`Publishes:\` line) then picks one of them arbitrarily | give each declaration its own name, or factor the second into a \`$ref\` at the first |
 | \`asyncapi.payload-undescribed\` (warn) | message(s) whose payload declares no shape at all — absent, or bare \`type: object\` with not one property. The name joins the spine while nothing defines what a consumer would read. A presence probe: a payload declaring a non-JSON \`schemaFormat\` (Avro) is never judged | declare \`properties\` on the payload, or the \`schemaFormat\` of its non-JSON schema |
@@ -116,7 +116,7 @@ and say it.
 | \`asyncapi.message-contested\` (warn) | two or more services declare they send one message name — every consumer's join picks one of them arbitrarily | namespace the message by its owning domain; one message has one producer, and which contract a consumer reads must not be a coin flip |
 | \`event.messages-unlinked\` (warn) | messages AND requirements exist but zero \`Publishes:\`/\`Consumes:\` lines join them — the event axis is vacuously green | link each requirement to the messages it governs |
 | \`event.ungoverned\` (warn) | message(s) declared in asyncapi.yaml that no requirement's \`Publishes:\`/\`Consumes:\` line names — \`api.ungoverned\`'s event twin, and the per-message half \`event.messages-unlinked\` cannot see: that code stays silent once even one message is linked | write the requirement that governs each named message, or drop the declaration |
-| \`covers.unknown\` (warn) | a \`Covers:\` entry in arch.spec.md resolves to no element, edge, alert or SLI — living and feature deltas alike | fix the id (the message offers close ones); a mistyped entry silently costs the coverage it was written for |
+| \`covers.unknown\` (warn) | a \`Covers:\` entry in arch.spec.md resolves to no element, edge, alert or SLI — living and feature deltas alike. Not raised for a service whose model.likec4 could not be read (\`c4.invalid\`, or \`spine.landscape-invalid\` for a model that extends the map): nothing is graded against a model nobody could read | fix the id (the message offers close ones); a mistyped entry silently costs the coverage it was written for |
 | \`usecase.step-unbacked\` | a hop of a \`#req-\`-tagged \`dynamic view\` in this service's own LikeC4 project — any \`.likec4\` beside model.likec4, or a view inside it — that NO relationship in model.likec4 backs. LikeC4 reports no error for it, so the diagram renders and the renderer's project parses; only this convicts it. The message reads \`<svc>: services/<tree>/<file> — dynamic view '<id>' step N\` | draw the edge in \`model { }\` (with \`metadata { op '<operationId>' }\` where it is a call), or, if the hop is a return step, write it as \`<target> <- <source>\` |
 | \`usecase.step-contested\` (warn) | two or more relationships in model.likec4 back one hop of a service-local flow and name DIFFERENT operations — an absent \`metadata { op }\` counts as a value — so nothing can say which one the hop exercises; \`details\` lists every candidate | give the candidates one operation, or draw the hop between the elements that name exactly one |
 | \`usecase.step-unlinked\` (warn) | the same code as the fleet row below, raised on a service-local flow: the relationship backing a hop of a \`#req-\`-tagged \`dynamic view\` beside model.likec4 carries no \`metadata { op }\` and no \`publishes\`/\`consumes\`, while the hop's caller is not a person and its target resolves to a real \`services/<id>/\` — the stand-in a model declares for a sibling service is the case that reaches it here. Never between two containers of THIS service: a service owes no operationId to itself. The \`--all\` row spells out all four mechanical guards | add \`metadata { op '<operationId>' }\` to the edge in \`model { }\`, or \`metadata { publishes '<message>' }\` / \`consumes\` where the hop is an event |
@@ -153,13 +153,13 @@ and say it.
 | \`gherkin.stale\` (warn) | a generated scenario's digest matches no living scenario while its requirement still exists — the spec moved under the file (a reworded scenario reports stale + missing together) | regenerate; never edit a generated file to catch it up |
 | \`gherkin.orphaned\` (warn) | a generated file whose requirement no longer exists in the living spec (a file for a feature still in flight is exempt — it answers to its feature until it archives) | regenerate; the orphaned file is deleted and reported |
 | \`gherkin.path-outside\` | this repo's \`gherkinDir\` resolves outside the repository — a \`..\` segment, an absolute path, or a symlink pointing away — so generating would write where nothing here can review it. Refused before any file is read, not repaired | point \`gherkinDir\` in loam.json at a directory INSIDE this repository; it is the suite's own home, and a path outside it is a write nobody's diff would show |
-| \`evidence.checked\` (ok) | every evidence pin on the federated verification records this service attested re-resolved clean against this working tree. Fires only in the service's own repo, like \`sources.*\` — from the docs repo the whole \`evidence\` family is silent | nothing — it is the confirmation |
+| \`evidence.checked\` (ok) | every evidence pin on the federated verification records this service attested re-resolved clean against this working tree. Fires only in the service's own repo, like \`sources.*\` — from the docs repo the service target's whole \`evidence\` family is silent, and only \`evidence.record-unreadable\` still fires there, on the feature target | nothing — it is the confirmation |
 | \`evidence.unpinned\` (ok) | agent-confirmed citations recorded before evidence pins existed, so nothing can grade their drift | the next \`loam verify <FEAT> --service <id> --record\` stamps pins; not work on its own |
 | \`evidence.unresolved\` (warn) | a pinned citation cannot be re-checked: the cited file is gone, unreadable, unsafe, not a regular file, or the cited line is past its end | re-read the evidence in this tree, re-answer, and re-record from this repo — a pin lint never moves the verdict by itself |
 | \`evidence.moved\` (warn) | a cited file's normalized sha256 differs from the pin while the cited line's text survives — the mildest drift: the file changed around the citation | re-read the cited file; re-record once the answers are re-checked |
 | \`evidence.line-changed\` (warn) | the cited line no longer says what the pin recorded — the citation no longer shows what it showed | re-read the evidence and re-answer; the claim may still be true, but this line no longer backs it |
 | \`evidence.token-missing\` (warn) | the cited file contained the literal the claim asserts (the operationId, message name or edge op the pin carries as \`token\`) at the attested commit, and no longer does — a token the commit never contained is warned once at record time and never stamped, so this grade always convicts a disappearance | check whether the code moved or the claim stopped being true; re-answer and re-record from this repo |
-| \`evidence.record-unreadable\` (warn) | a feature's verification.yaml exists but cannot be read as a record (broken YAML, a malformed \`evidence_pins\` block, a summary contradicting its claims) — none of its evidence was checked, and a silent skip would read as clean | repair the YAML by hand, or re-record from this repo; loam never overwrites a record it could not read |
+| \`evidence.record-unreadable\` (warn) | a file of a feature's verification record (its \`verification.yaml\`, or a \`verification/<svc>.yaml\`) exists but cannot be read as a record (broken YAML, git conflict markers, a malformed \`evidence_pins\` block, a summary contradicting its claims) — none of its evidence was checked, and a silent skip would read as clean | follow the repair the finding names for that file: this service's own \`verification/<svc>.yaml\` may be repaired, or deleted and re-recorded from this repo; the one-file \`verification.yaml\` may hold other services' attestations, so it is repaired or restored from version control, never deleted. loam never overwrites a record it could not read |
 
 \`--feature <FEAT-id>\` — a change's three axes against each other. The SAME checks
 gate \`loam archive\` (errors block it; warnings never do), so a clean run here is
@@ -180,25 +180,27 @@ what lets a feature ship:
 | \`c4-api.op-undefined\` | an edge calls an operation the target does not expose | a broken contract between services — fix the caller or add the endpoint |
 | \`c4-api.op-pending\` (warn) | the called operation is defined by another feature in flight | archive that feature first |
 | \`c4-api.op-deprecated\` (warn) | a NEW tagged edge consumes an operation the living provider's OpenAPI marks \`deprecated: true\` — building new consumption on a dying op (quiet when this feature's own openapi delta drops the flag: that IS the un-deprecation) | point the edge at the replacement operation, or say why the deprecated one is right; never gates archive |
-| \`c4-api.op-removing\` | a NEW tagged edge consumes an operation this feature removes | remove or redirect the new edge; one feature cannot retire and add consumption of the same operation |
+| \`c4-api.op-removing\` | a NEW tagged edge consumes an operation this feature removes — with a removal marker, or by defining another operation at its method and path so the merge leaves it defined nowhere | remove or redirect the new edge; one feature cannot retire and add consumption of the same operation |
 | \`openapi.remove-target-missing\` | an \`x-loam-remove: true\` marker's exact path+method does not exist in living OpenAPI | update the stale marker to the current slot, or drop it if the operation is already gone |
 | \`openapi.remove-target-mismatch\` | the marker's operationId differs from the living operation at that path+method | name the living operation exactly; loam never deletes the different operation occupying the slot |
-| \`openapi.remove-marker-missing\` | a REMOVED requirement governs an operation but the feature has no removal marker | add the exact path/method operation with its operationId and \`x-loam-remove: true\` to the feature openapi.yaml |
+| \`openapi.remove-marker-missing\` | a REMOVED requirement governs an operation the service's living contract still defines, but the feature has no removal marker for it. Owed only while there is a living operation to retire: not for an id the service's own contract does not define (a consumer's REMOVED requirement naming another service's operation), and not for one this delta already replaces at its method and path. A living contract that does not parse proves neither, so the marker is still owed there | add the exact path/method operation with its operationId and \`x-loam-remove: true\` to the feature openapi.yaml |
 | \`openapi.remove-marker-unjustified\` | a removal marker is not named by any REMOVED requirement's \`Operations:\` line | remove the marker or retire the governing requirement in the same feature |
 | \`openapi.remove-marker-anonymous\` | an \`x-loam-remove: true\` marker with no \`operationId\` — loam cannot tell which operation it retires, and the marker itself would be written into the living contract | name the operation the marker retires, exactly as the living contract spells it |
-| \`openapi.remove-op-consumed\` | the feature retires an operation the LIVING fleet still consumes — a landscape edge's \`metadata { op }\`, or another service's living requirement naming it | fix the consumer in the same feature (redirect the edge, retire its requirement), or archive with \`--approve\` if the consumer is already gone in code |
+| \`openapi.remove-op-consumed\` | the feature takes out of the contract an operation the fleet would still consume after this merge — read once for the gate and \`loam diff\` alike: an edge of the \`architecture/\` project with \`metadata { op }\` into the provider; another service's requirement (spec.md or arch.spec.md) whose \`Operations:\` line names it, unless that service's own contract defines the same id (then it names its own); a use-case hop attributed to it; and the provider's OWN spec.md requirements (an arch.spec.md \`Operations:\` line is never graded against its own contract, so the provider's strands nothing) and self-edges still naming it. Every requirement is read as the merge would leave it — one this feature MODIFIES to drop the id or REMOVES no longer counts, another service's included, and an unappliable spec delta fails closed. Two shapes: a removal marker retires it, or the delta defines ANOTHER operation at its method and path, and the contract the merge would write then defines it nowhere (the merge writes per method and path, so it replaces it there). The message names what replaces it and where; \`details[]\` lists the consumers. A consumer document loam cannot read — a spec.md or arch.spec.md that is not UTF-8, the provider's own spec.md included, or a service id two directories claim — refuses too, named in \`details[]\`: nobody could prove it does not name the operation. An edge into the provider drawn with no \`metadata { op }\`, or a use-case hop whose edges name different operations, does not refuse (\`loam diff\` lists them as doubts) | make each document listed readable (re-save it as UTF-8, or leave one directory per service id); fix each consumer in the same change — drop or redraw the edge by editing the living map (the landscape merge only adds edges, so a \`delta.likec4\` can never take one away), MODIFY or REMOVE the requirement in this feature's \`specs/<service>/\` delta (a REMOVED one owes no marker where the overwrite already takes the operation out) — or archive with \`--approve\` if the consumer is already gone in code. An overwrite: define the replaced operation at another address in the same delta if it is to stay; for a rename, redraw the living edge and restate the governing requirement as a MODIFIED naming the new operation |
+| \`openapi.op-revived\` (warn, gates archive) | the feature's openapi.yaml spells an operation the living contract no longer has, and an ARCHIVED feature's removal marker retired it — or spells it at an address an archived feature MOVED it away from (or retired it from, before another re-added it elsewhere), so the merge would answer it at both addresses (one operationId at two slots). Judged on the contract the merge would write: an operation the living contract still holds that ends up at one address is not graded — moved back with its own removal marker where it lives now, or swapped out there by another operation, with or without an operationId — and a removal marker where the operation does not live removes nothing, so it excuses nothing. The message names the operation, the archived feature(s), what each did there (moved it, and where to, or retired it) and, apart from that, where it lives now — and, when another operation lives at the address the delta spells it at, names that one too (one written with no operationId by what it is): the merge writes per method and path, so archiving replaces it there. Absent from living reads like an addition, so the merge would put it back. Read from the markers under \`features/archive/\`, counted only where that feature's snapshot shows the merge carried them out: an operation removed by hand-editing a living contract, or retired by an archive since deleted from disk, is invisible to it | retired: delete the quote if you only restated it; archive with \`--approve\` if the feature brings it back on purpose (drop its \`x-loam-based-on\` first — a pin over nothing is \`openapi.baseline-invalid\`). Two addresses: delete the quote and make any change at the address the message names; to move it back on purpose, add a removal marker for it at that address in the same delta (or define another operation there) — and where another operation lives at the quoted address now, the delta replaces it, so define that one at another address in it if it is to stay. Where the delta already spells that address, no marker can stand beside what it holds there, and the message offers \`--approve\` instead |
 | \`c4-event.message-undefined\` | a tagged edge \`publishes\`/\`consumes\` a message its bound service's asyncapi contract — as this feature's merge would leave it; feature ∪ living where no delta exists — declares no matching \`action: send\`/\`receive\` operation for | declare the operation in the feature's asyncapi.yaml, or correct the edge |
 | \`c4-event.message-pending\` (warn) | the named message is introduced by another feature in flight | archive that feature first |
 | \`spec-event.message-undefined\` | a delta requirement's \`Publishes:\`/\`Consumes:\` line names a message the service's asyncapi contract — as this feature's merge would leave it, so a retired declaration stops answering and a leftover line on a surviving requirement is caught before it breaks the post-archive fleet — does not declare in that direction; the same code validate gives the living-side breach | declare it in the feature's asyncapi.yaml, retire the line with its requirement, or correct it |
 | \`spec-event.message-pending\` (warn) | the named message is introduced by another feature in flight | archive that feature first |
 | \`asyncapi.baseline-missing\` (warn, gates archive; one per service) | slots or component surfaces in this feature's asyncapi.yaml carry no baseline pin (\`x-loam-based-on\` / \`x-loam-baselines\`) | run \`loam rebase <FEAT>\` — until then the merge cannot tell the slots and surfaces you EDITED from the ones you merely restated, and every restated one would revert whatever landed on it. \`--approve\` merges unpinned deliberately |
 | \`asyncapi.baseline-stale\` | the living slot, or the living component surface, changed after this delta pinned it | somebody landed a change in between. Re-read the living value, fold in what you still mean, then \`loam rebase <FEAT>\` |
-| \`asyncapi.baseline-invalid\` | an \`x-loam-based-on\` that is not a digest or one on a slot the living contract has no counterpart for; a malformed \`x-loam-baselines\` record, or an entry of it naming a component surface the delta does not declare (or whose living value is gone) | \`loam rebase\` writes both; a new channel, operation, message or component has no living version to be based on, so it carries no pin |
+| \`asyncapi.baseline-invalid\` | an \`x-loam-based-on\` that is not a digest or one on a slot the living contract has no counterpart for; a malformed \`x-loam-baselines\` record, or an entry of it naming a component surface the delta does not declare (or whose living value is gone) | \`loam rebase\` writes both; a new channel, operation, message or component has no living version to be based on, so it carries no pin. A pinned slot whose living one a parallel feature has since REMOVED lands here too: re-read the living contract and delete the slot from the delta, unless this feature deliberately brings it back — then drop the pin and archive with \`--approve\` past \`asyncapi.slot-revived\`. A pinned \`components.messages\` key whose message a parallel feature MOVED elsewhere (another key, or inline under a channel) — or retired there, before another re-declared it elsewhere — lands here as well, and the message names where it is declared now: delete the quote and make any change there — archiving past it would declare the name in two places; to move it back on purpose, drop the pin and take the name out of there as \`asyncapi.slot-revived\`'s row says |
+| \`asyncapi.slot-revived\` (warn, gates archive) | the feature's asyncapi.yaml declares a \`channels\`/\`operations\` slot, or a message by name, that the living contract no longer has, and an ARCHIVED feature retired it — a slot marker, or a channel removal that took the channel's inline messages (named from that feature's \`.loam-before/\` snapshot) — or declares a message at a key an archived feature MOVED it away from (or retired it from, before another re-declared it elsewhere), so the merge would declare its name in two places (the message says what that feature did there, where the name is declared now, and any other message declared at that key now, which archiving replaces there) — judged on the contract the merge would write, so a delta that also takes the name out of where it is declared now (restating or retiring the channel it stands inline in, a marker at its \`components.messages\` key, or another message declared at that key) is moving it back, and is not graded. Absent from living reads like an addition, so the merge would put it back. A message inline under a channel the delta brings back is that channel's finding, unless the merge would also declare its name elsewhere — then it is a two-places finding of its own. A removal made by hand-editing a living contract, or an archive since deleted from disk, is invisible to it | retired: delete the quote if you only restated it; archive with \`--approve\` if the feature brings it back on purpose. Two places: delete the quote and make any change where the message says it is declared now; to move it back on purpose, take it out of there in the same delta — a removal marker at a \`components.messages\` key, AND every channel (or operation) the message names as still \`$ref\`-ing that key restated with the \`$ref\` pointed at the quoted key (retired alone, the key leaves them pointing at nothing, and their send stops sending the message: \`asyncapi.remove-message-consumed\`); for a declaration inline under a channel, restate channel \`<ck>\` with a \`$ref\`, or retire channel \`<ck>\` (a marker nested on the inline message retires nothing: \`asyncapi.remove-marker-inline\`); where another message is declared at the quoted key now, define it at another key to keep it. Where the delta already spells that key, the message offers \`--approve\` instead |
 | \`asyncapi.remove-target-missing\` | an \`x-loam-remove: true\` marker addresses a slot the living asyncapi does not have | update the stale marker to the current key, or drop it if the slot is already gone |
 | \`asyncapi.remove-target-mismatch\` | the marker's message name differs from the living declaration at that key | name the living message exactly; loam never deletes a different message occupying the slot |
-| \`asyncapi.remove-marker-missing\` | a REMOVED requirement's \`Publishes:\`/\`Consumes:\` line names a message the living contract still declares, with no matching marker in the feature's asyncapi.yaml | add the \`components.messages\` entry with the message's name and \`x-loam-remove: true\`; a message the living contract declares only INLINE under a channel is retired by that channel's own removal marker (\`channels.<key>: {x-loam-remove: true}\`) instead |
+| \`asyncapi.remove-marker-missing\` | a REMOVED requirement's \`Publishes:\`/\`Consumes:\` line names a message the living contract still declares, and the contract the merge would write still declares it, with no matching marker in the feature's asyncapi.yaml (a message this delta already takes out — a slot re-keyed to another name — owes none) | add the \`components.messages\` entry with the message's name and \`x-loam-remove: true\`; a message the living contract declares only INLINE under a channel is retired by that channel's own removal marker (\`channels.<key>: {x-loam-remove: true}\`) instead |
 | \`asyncapi.remove-marker-unjustified\` | a message-removal marker no REMOVED requirement's \`Publishes:\`/\`Consumes:\` line justifies (channel and operation slots need exactness only — requirements never join on their keys) | remove the marker, or retire the governing requirement in the same feature |
-| \`asyncapi.remove-message-consumed\` | the feature retires a message the LIVING fleet still consumes — a landscape \`consumes\` edge, or another service's living \`Consumes:\` requirement | fix the consumer in the same feature (drop the edge, retire its requirement), or archive with \`--approve\` if it is already gone in code |
+| \`asyncapi.remove-message-consumed\` | the feature retires a message — a marker, or a removal or edit that stops the service sending it (a slot re-keyed, a send turned to receive) — that the fleet would still name after this merge: a \`consumes\` edge of the \`architecture/\` project, another service's \`Consumes:\` line in either spec file, or a use-case hop backed by such an edge, while nothing would still send the message after this merge (another service's contract, as the merge leaves it, keeps them served, and so does an \`#external\` element whose \`publishes\` edge is in the living map — the outside producer \`spine.message-unproduced\` accepts — unless this feature's \`specs/<service>/\` makes that element a service); or the provider's OWN \`Publishes:\` line or \`publishes\` edge (the spine grades that edge on its source), whoever else sends it — each read as the merge would leave it; \`details[]\` lists them. A consumer document loam cannot read (a spec file that is not UTF-8, the provider's own included) or a service id two directories claim refuses too, named in \`details[]\` — another service's only while nothing would still send the message | make each document listed readable (re-save it as UTF-8, or leave one directory per service id); fix each in the same change (drop the consumes edge, or drop or redraw the provider's publishes edge, in the living map, MODIFY or REMOVE the requirement in this feature's \`specs/<service>/\` delta — a REMOVED one owes no marker for a message the merge already takes out), keep it sent — by an operation in this service, or, for the consumers, by one in another service's asyncapi.yaml (living or in this feature's delta) or by an \`#external\` element's \`publishes\` edge in the living map — or archive with \`--approve\` if it is already gone in code |
 | \`asyncapi.message-conflict\` (warn) | two features in flight add or edit the same (service, message) | whichever archives second replaces the other's declaration wholesale — coordinate before either ships |
 | \`c4.op-ungoverned\` (warn) | an operation is called but no requirement governs it | write the requirement |
 | \`c4.op-link-missing\` (warn) | a "Calls" edge in the delta with no \`metadata { op }\` | link it to the operationId |
@@ -206,7 +208,7 @@ what lets a feature ship:
 | \`api.op-unconsumed\` (warn) | an added operation no edge consumes | model the caller, or say why it is provider-only |
 | \`service.no-requirement-delta\` (warn) | a new service with no spec delta | write \`specs/<svc>/spec.md\` |
 | \`scaffold.placeholder\` (warn, gates archive) | a feature document still carries \`loam new\`'s exact placeholder text — a \`TODO — name the behaviour\` requirement, a \`TODO — name the case\` scenario, an \`<angle-bracket>\` fill-in, or a \`TODO — what this service owns\` description | write the real content; the merge would otherwise publish a requirement or description nobody authored. \`--approve\` overrides |
-| \`intent.empty\` (warn, gates archive) | intent.md is missing, or its Why/Scope hold nothing outside the scaffold's own comments | write why the feature exists — it is the first thing a reviewer reads. \`--approve\` overrides |
+| \`intent.empty\` (warn, gates archive) | intent.md is missing, or its Why/Scope hold nothing outside the scaffold's own comments — questions under \`## Open questions\` do not count | write why the feature exists — it is the first thing a reviewer reads. \`--approve\` overrides |
 | \`archedge.uncovered\` (warn) | no scenario names a tagged edge (a heuristic) | write the scenario, or say why the edge needs none |
 | \`c4.uncovered\` (warn) | a NEW tagged element or edge in delta.likec4 that no arch requirement covers via \`Covers:\` — the mechanical check, not the heuristic above | add the requirement to \`specs/<svc>/arch.spec.md\` (outbox? retries? alerts?), or the architectural obligations ship unchecked |
 | \`capability.uncovered\` (warn, GATES archive) | a requirement a feature's \`features/<FEAT>/capabilities/<id>/spec.md\` ADDS that no ADDED or MODIFIED requirement in the same feature's \`specs/\` deltas names with \`Realizes: <capability-id>#<Requirement-ID>\`, subject = the capability id. A WARNING because the document is legal — writing a promise ahead of the fleet is the intended use — that GATES because the merge is what is unsafe: once it lands, the only thing that will ever mention the promise again is \`capability.requirement-unrealized\`, a fleet-scope warning nobody reads. MODIFIED is exempt (the promise may already be realized by living text), and a requirement with no \`Requirement-ID:\` is left to \`capability.requirement-unidentified\` alone | add the \`Realizes:\` line to the service requirement that carries part of the promise; or, if the promise CROSSES services, write the flow that keeps it as \`features/<FEAT>/usecases/<name>.likec4\` — a views-only document holding one \`dynamic view\` tagged \`#cap-<capability>\` and \`#req-<requirement>\`, which \`loam archive\` merges into \`architecture/usecases/\` and \`loam unarchive\` takes back; or \`loam archive <FEAT> --approve\` to land the promise ahead of the fleet and let \`capability.requirement-unrealized\` carry it |
@@ -216,7 +218,7 @@ what lets a feature ship:
 | \`usecase.flow-exists\` | a \`features/<FEAT>/usecases/<name>.likec4\` whose flow the LIVING \`architecture/usecases/\` already holds. The merge is a whole-file copy, so it would replace an authored hop sequence wholesale — and \`--approve\` does NOT move this one (\`overridable: false\` in the \`--json\` refusal), because a \`dynamic view\`'s ordered steps are written down in no other document the fleet keeps. A feature-local flow INTRODUCES a use case; it does not rewrite one | delete the feature's copy and edit \`architecture/usecases/<name>.likec4\` directly in the same change, where git produces an ordinary conflict if somebody else is editing it too |
 | \`deployment.doc-exists\` | a \`features/<FEAT>/deployment/<name>.likec4\` whose file the LIVING \`architecture/\` already holds. The merge is a whole-file copy, so it would replace an authored topology wholesale, and \`--approve\` does NOT move it — the same act, and the same severity, as \`usecase.flow-exists\` one axis over. The collision is on the FILE, never on what is inside it: two features may both \`extend\` one living region from documents of their own and both archive | delete the feature's copy and edit \`architecture/<name>.likec4\` directly in the same change — or, to ADD to what that file declares, rename the feature's document and say \`extend\` in it |
 | \`deployment.doc-invalid\` | a \`features/<FEAT>/deployment/*.likec4\` loam could not read against the map this feature's own merge would leave behind — a parse error, an unresolved element, or a landscape merge that itself refuses. The corpus is the feature's \`deployment/\` PLUS the living \`architecture/\` documents it \`extend\`s, so the fault may be in either and every message names its file. \`--approve\` does not move it: the flag overrides loam's judgement about coherence, never its ability to read an axis | fix what the messages name. A document instancing an element only this feature's \`delta.likec4\` adds is LEGAL and resolves — that is what the merge preview is for; one naming an element the merge does not land is the case this refuses |
-| \`deployment.doc-reserved\` | a \`features/<FEAT>/deployment/<name>.likec4\` whose name loam owns inside \`architecture/\`: \`subsystems.likec4\` (generated, overwritten wholesale by \`loam subsystem sync\`, and parsed by nothing — so topology landing there is invisible from the moment it archives), \`landscape.likec4\` (spliced into, never replaced), or any path under \`usecases/\` (the flow tree). Refused whether or not the target exists, which is the point: two of the three fail silently when it does not | rename the feature's document — its name is yours to choose, and \`extend\` is how it adds to what a living document already declares |
+| \`deployment.doc-reserved\` | a \`features/<FEAT>/deployment/<name>.likec4\` whose name loam owns inside \`architecture/\`: \`subsystems.likec4\` and \`services.likec4\` (both generated, overwritten wholesale by \`loam subsystem sync\`, and parsed by nothing — so topology landing in either is invisible from the moment it archives), \`landscape.likec4\` (spliced into, never replaced), or any path under \`usecases/\` (the flow tree). Refused whether or not the target exists, which is the point: three of the four fail silently when it does not | rename the feature's document — its name is yours to choose, and \`extend\` is how it adds to what a living document already declares |
 | \`delta.unknown-section\` | a heading that nearly matches the delta grammar | fix it — everything under it merges as NOTHING today, silently |
 | \`delta.no-delta-sections\` | requirements, but no \`## ADDED/MODIFIED/REMOVED Requirements\` section anywhere — the whole delta would merge nothing | put every changed requirement under its delta section |
 | \`delta.requirement-not-merged\` (warn, gates archive) | a requirement under a prose heading (\`## Behavior\`) instead of a delta section | move it under \`## ADDED\`/\`## MODIFIED\`/\`## REMOVED Requirements\` — as written, archive drops it. If it really is documentation, quote it under \`## Requirements\`, which is exempt |
@@ -235,27 +237,28 @@ what lets a feature ship:
 | \`delta.baseline-stale\` | the living requirement changed after this delta was written against it | someone landed a change in between and this MODIFIED would replace it outright. Re-read the living requirement, fold in what you still mean, then \`loam rebase <FEAT>\`. Re-pinning without re-reading is how you overwrite them on purpose |
 | \`delta.baseline-missing\` (warn, gates archive) | a MODIFIED/REMOVED requirement with no \`Based-On:\` | run \`loam rebase <FEAT>\` — until then nothing can say whether the living text moved under this delta, and archive refuses to merge it. Expected on deltas adopted from OpenSpec, which never carried the line: one rebase pins the whole feature, and \`--approve\` merges unpinned deliberately |
 | \`delta.baseline-invalid\` | a \`Based-On:\` that is not a digest, declared twice, or sitting on an ADDED requirement | \`loam rebase\` writes the value; an ADDED requirement has no living version to be based on, so drop the line or make it MODIFIED |
+| \`evidence.record-unreadable\` (warn) | a file of this feature's verification record (\`verification.yaml\`, or a \`verification/<svc>.yaml\`) exists but cannot be read as a record — broken YAML, git conflict markers after a merge, a shape that is not a record, a summary contradicting its claims. The same code and sentence the service target raises from a service repo; here it fires from anywhere, the docs repo included, because the record lives there. Readability only: the verdict stays \`loam verify\`'s and \`loam status\`'s, and as a warning it never stops \`loam archive\` | repair the file the finding names, following the recipe it carries: a \`verification/<svc>.yaml\` holds one service's word and may be deleted and recorded again from that service's repo; the one-file \`verification.yaml\` may hold other services' attestations, so it is repaired or restored from version control, never deleted. loam never overwrites a record it could not read |
 
 \`--all\` — everything above for every target, plus the fleet cross-check:
 
 | code | what it means | what to do |
 |---|---|---|
 | \`landscape.missing\` | \`architecture/landscape.likec4\` does not exist — an ERROR as soon as \`services/\` holds one service, a warning only in an empty docs repo | create it: a \`specification { ... }\` block declaring the kinds, then a \`model { ... }\` block with one bound element per service (\`metadata { service '<id>' }\`) and one edge per cross-service call carrying \`metadata { op '<operationId>' }\`. With no fleet map every cross-service check is blind, not passing |
-| \`landscape.invalid\` | the living landscape does not parse. The fleet map is graded as the \`architecture/\` project and NOTHING ELSE — the landscape plus every \`architecture/**/*.likec4\` except the generated \`subsystems.likec4\` — whatever shape the service models take. That is deliberate: the renderer's root project is wider (it also holds every extending model), so a hop in \`architecture/usecases/\` naming a CONTAINER an extending model declares renders perfectly and is \`landscape.invalid\` here. A cross-service flow names service elements; a container-level flow lives beside the model that declares the container. One broken service model must never blank the fleet's own map | fix it first — the fleet cross-check cannot run against a document nobody can read. If the unresolved name is a container an extending model declares, the reference belongs one altitude down whatever carries it: a use-case hop moves beside that service's model.likec4 and is tagged \`#req-\`; a model edge names the SERVICE on the map and the container in the service's own model |
+| \`landscape.invalid\` | the living landscape does not parse. The fleet map is graded as the \`architecture/\` project and NOTHING ELSE — the landscape plus every \`architecture/**/*.likec4\` except the generated views files (\`subsystems.likec4\` and \`services.likec4\`) — whatever shape the service models take. That is deliberate: the renderer's root project is wider (it also holds every extending model), so a hop in \`architecture/usecases/\` naming a CONTAINER an extending model declares renders perfectly and is \`landscape.invalid\` here. A cross-service flow names service elements; a container-level flow lives beside the model that declares the container. One broken service model must never blank the fleet's own map | fix it first — the fleet cross-check cannot run against a document nobody can read. If the unresolved name is a container an extending model declares, the reference belongs one altitude down whatever carries it: a use-case hop moves beside that service's model.likec4 and is tagged \`#req-\`; a model edge names the SERVICE on the map and the container in the service's own model |
 | \`service.id-invalid\` | a \`services/<id>/\` directory whose name is not a legal service id — every authoring command refuses it, so nothing in that directory can be changed through loam. Fleet scope only: the SET of service directories is what makes the id a question, and a \`--service\` run is already refused by its own guard before it gets this far (the guard refuses only a name that neither exists as a directory nor is a legal id — a badly-named directory that DOES exist resolves through the enumeration and grades as an ordinary target, still without this finding). Graded before the map is opened, so it stands even when the landscape is missing or unreadable | rename the directory, then update its \`service:\` frontmatter, its \`metadata { service }\` binding in the landscape, and any \`features/<FEAT>/specs/<id>/\` naming it |
 | \`subsystem.unmarked\` | a directory under \`services/\` that is neither a subsystem (no \`subsystem.yaml\`) nor a service (no service artifact), with directories beneath it — the shape an ordinary merge produces when one branch deletes an emptied subsystem's marker while another moves a service in. The services beneath STAY enumerated and the finding names every one of them: the fleet is never reported smaller than it is | restore \`subsystem.yaml\` in that directory (an empty file is a valid marker), or move the directories out |
 | \`subsystem.marker-misplaced\` | \`subsystem.yaml\` sitting BESIDE service artifacts (spec.md, model.likec4, …) — a directory is a subsystem or a service, never both; it stays classified as a service | delete the marker, or move the artifacts into a service directory of their own inside the group |
 | \`subsystem.name-collision\` | one name claimed by two or more directories in the \`services/\` tree — service ids and subsystem names share one flat namespace, unique at any depth, because a service's identity is its leaf directory name alone and placement never disambiguates it. The message names every claimant | rename all but one, then update whichever frontmatter, landscape bindings and \`features/<FEAT>/specs/<id>/\` name the renamed service |
 | \`subsystem.name-invalid\` | a subsystem directory name that breaks the id grammar (a space, a \`..\`, a Windows-reserved stem, a trailing dot) — subsystem names take the service-id grammar because both become directory names in one shared tree. Its services stay enumerated meanwhile | rename the directory to a legal name |
 | \`subsystem.invalid\` | a \`subsystem.yaml\` that exists but cannot be read as subsystem metadata — presence still classifies the directory as a subsystem (content is metadata, never identity), and exactly one finding is emitted per file | fix the file: a YAML mapping with optional \`title\`, \`description\` and \`owner\`; never \`members\` — the directory itself is the membership record. An empty file is also a valid marker |
-| \`subsystem.views-stale\` | \`architecture/subsystems.likec4\` — the GENERATED file holding one LikeC4 view per subsystem — does not match the tree: it drifted after a move, it is absent while subsystems exist, it lingers after the last subsystem was removed, or the map's global style groups changed. Styling restales it twice over: declaring or removing a group named \`subsystems\` changes whether the generated views carry the \`global style subsystems\` line, and declaring a group under ANY other name changes the disclosure comment that names what is available — either way the deterministic re-render differs from the bytes on disk. The census reads every \`.likec4\` under \`architecture/\` the root \`likec4.config.json\` does not exclude, so a palette in a sibling counts. One error on one file, graded by byte comparison against that re-render (no check ever reads the file's content) | run \`loam subsystem sync\` — the single regenerator. Never edit the file by hand; authored views belong in the landscape or a file of your own. \`sync\` refuses to rewrite this file while \`architecture/\` does not parse (\`action: "blocked"\`) — fix the map first; \`validate\` already skips the staleness question in that state |
+| \`subsystem.views-stale\` | a GENERATED views file under \`architecture/\` does not match the tree and the map. There are TWO, written by the same command in the same commit, and each earns its own finding naming its own path: \`architecture/subsystems.likec4\` (one view per subsystem) and \`architecture/services.likec4\` (one overview view per service the fleet map draws — the service, its own interior, every peer the map gives it, and \`of <element>\`, which is what makes every other view drill into it). A file is stale when it drifted after a move, is absent while the thing it mirrors exists, lingers after the last of them was removed, or the map moved under it — a service added, an edge drawn, a subsystem renamed, or the global style groups changed. Styling restales the subsystem file twice over: declaring or removing a group named \`subsystems\` changes whether its views carry the \`global style subsystems\` line, and declaring a group under ANY other name changes the disclosure comment that names what is available; the per-service file reads a group named \`services\` the same way. The census reads every \`.likec4\` under \`architecture/\` the root \`likec4.config.json\` does not exclude, so a palette in a sibling counts. One error per stale file, graded by content comparison against the deterministic re-render — never by reading what a view SHOWS (docs/DESIGN.md rule 26) | run \`loam subsystem sync\` — the single regenerator for both files. Never edit either by hand; authored views belong in the landscape or a file of your own, and an authored view \`of\` the same element keeps precedence whenever its file sorts first (\`landscape.likec4\` does, ahead of \`services.likec4\`), with both still reachable. \`sync\` refuses to rewrite a generated file while \`architecture/\` does not parse (\`action: "blocked"\`) — fix the map first; \`validate\` already skips the staleness question in that state. A docs repo that has not run \`sync\` since \`architecture/services.likec4\` existed sees this once for that file; one run clears it |
 | \`service.likec4-config-missing\` (warn) | a model that STANDS ALONE — it declares its own \`specification\` block, so it is parsed alone and cannot share a project with the map — with no \`likec4.config.json\` beside it. It renders only as a project of its own and this one has none: a box on the fleet map with nothing renderable inside it. One warning per service, on the fleet target, only when the root \`likec4.config.json\` exists (\`loam doctor\` prints that one); never gating, because no loam check reads the model any differently. A model that EXTENDS the map never earns this — it belongs to the root project | run \`loam subsystem sync\` — it creates the file (create-only: a file that already exists is yours and is never touched). Never hand-write it; the bytes are a function of the service id, and the writer spells them once |
 | \`service.likec4-config-stray\` (warn) | the mirror: a \`likec4.config.json\` beside a model that EXTENDS the fleet map. The renderer registers that file as a project of its own rooted at that directory, so \`likec4 validate .\` at the docs root refuses without \`--project\`, and wherever that nested project claims the model it parses alone, out of the root project where the map's kinds are: the model does not resolve and \`export json --project fleet\` loses the service's containers (measured, likec4 1.59.2 — it happened on a seeded fleet and not on \`examples/docs\`). Fleet target, root-gated like its siblings, never gating | run \`loam subsystem sync\` — it deletes the file (or delete it yourself). loam never writes one beside an extending model, so this one is a leftover from before the model migrated, or was hand-written |
 | \`service.model-excluded\` (warn) | a model that EXTENDS the fleet map whose directory the root \`likec4.config.json\`'s \`exclude\` covers — or whose \`model.likec4\` a FILE-shaped entry (\`services/**/model.likec4\`) names; the message says which shape it found. An entry is read the way the renderer reads it: a bare entry is a raw path PREFIX from a \`/\` boundary, so \`services\`, \`services/\`, \`services/*\`, \`services/**\`, \`services/**/*\`, a wildcard segment in the middle (\`services/*/legacy\`) and the bare \`services/pay\` all cover \`services/payment-service\` — while \`services/pay/**\` wants the literal separator and covers nothing there. The renderer never loads the model, so the service is a box with nothing inside it from the docs root, while every loam check still grades it perfectly: the gap is invisible except here. The finding quotes the entry verbatim, because the repair is to edit that line | for a DIRECTORY entry, run \`loam subsystem sync\` — it rewrites the root project's \`exclude\` to cover exactly the models that stand alone, keeping every entry that is not about \`services/\` in the order the team wrote it. For a FILE-shaped entry sync repairs nothing: remove or narrow that line by hand, then re-run |
 | \`service.model-unexcluded\` (warn) | the mirror of that one: a model that STANDS ALONE whose directory the root \`exclude\` does NOT cover. The renderer merges it into the root project and reports every kind and element it declares as a duplicate of the map's — which blanks the whole root project, not just this service. The most damaging of the four, and the one a fresh scaffold walks into the moment somebody writes a model in the old shape. An entry already covering the directory in any of its spellings satisfies it — no second glob is wanted, and none is appended | run \`loam subsystem sync\` — it adds \`services/<tree>/**\` to the root project's \`exclude\`. Or migrate the model to extend the map (SCHEMA.md, "Two shapes of a service model"), after which no exclusion is wanted |
 | \`landscape.excluded\` (warn) | the same root \`exclude\` list, one level up: an entry covering \`architecture/landscape.likec4\` itself. The renderer then loads NO fleet map — it draws nothing, and every model that EXTENDS the map resolves against nothing in the root project, which is also what WOULD turn \`c4.fleet-project-invalid\` into a page of unresolved references — measured on the packaged example fleet, one authored line came back as 161 of them. So that check is not graded at all while this entry stands, and this finding is the only line in the run that names the cause; remove the entry and the fleet project is graded again. loam is otherwise unaffected: the architecture loader keeps the map whatever the list says, so every grade in the run is right, and that is exactly why the state was invisible until this code existed. An entry is matched as a FILE path here, not as a directory, so \`architecture/*.likec4\` — a line somebody wrote for a palette — covers it while \`services/**\` and \`features/**\` do not. Quoted verbatim, because the repair is to edit that line | remove the entry, or narrow it to the paths it was written for. NOT \`loam subsystem sync\`: that command maintains only the \`services/\` entries in the list and leaves every other line exactly as the team wrote it, so it would report success and change nothing |
-| \`c4.fleet-project-invalid\` (warn) | every document reads clean where loam grades it, and the ONE project the renderer builds out of them does not parse. \`--all\` only, only when at least one extending model exists, the map itself parses, and the root \`exclude\` does not cover the map (\`landscape.excluded\` then names that one entry and this check stands down behind it, because this load reads what the renderer reads and has no floor under the map): loam walks the docs root and loads what the renderer's root project loads — everything the root \`exclude\` leaves, minus the generated \`subsystems.likec4\`, minus every STANDALONE service directory (\`service.model-unexcluded\` owns that state), minus \`features/\` (a delta carries its own \`specification\` and the directory is transient) — and reports each error that is NOT already present in the map alone, in some per-service project, or in a service-flow project the same run made. A \`.likec4\` in a SUBSYSTEM directory, above every service, is in that set. That difference is exactly the class no per-service grade can see: two services each declaring \`tag req-AUTH\` locally, two models adding the same child id under one element, a broken untagged sibling nobody opted in. All of them are renderer-fatal and all of them were silent. \`locations[0]\` is the file the error is IN, \`details\` carry \`<path>: L<n>: <error>\` 1-based — path, colon, space, then the line, exactly as the message's own head spells it, so an agent splitting on the separator gets the same two halves from either — and the message tail names the failure it actually is — a double declaration, an unresolved reference, or neither. \`subject\` is the service whose directory holds the file, where there is one | declare it once — in \`architecture/landscape.likec4\`, or in the single service that owns it — at the file and line the message names. Never by excluding the directory: that hides the model from the renderer instead (\`service.model-excluded\`) |
-| \`subsystem.view-id-collision\` | a document the root project reads declares a view whose id is one loam GENERATES into \`architecture/subsystems.likec4\`. LikeC4 merges every file of a project into one model and view ids are a flat namespace there, so the renderer refuses the WHOLE project and draws nothing — while every other check here stays green. Under \`--all\` the census covers every EXTENDING model's authored view ids as well as the landscape's, because those documents are in the same root project now; a standalone model's are not, since its views live in a project of its own. Only a real collision is reported: a \`subsystem_\`-looking id matching no current subsystem breaks nothing yet, and fires on the run after somebody creates that subsystem | rename the view in the file the finding names. Ids beginning \`subsystem_\` are loam's to mint; \`architecture/subsystems.likec4\` is generated (\`loam subsystem sync\`) and is never hand-edited |
+| \`c4.fleet-project-invalid\` (warn) | every document reads clean where loam grades it, and the ONE project the renderer builds out of them does not parse. \`--all\` only, only when at least one extending model exists, the map itself parses, and the root \`exclude\` does not cover the map (\`landscape.excluded\` then names that one entry and this check stands down behind it, because this load reads what the renderer reads and has no floor under the map): loam walks the docs root and loads what the renderer's root project loads — everything the root \`exclude\` leaves, minus the generated views files (\`subsystems.likec4\` and \`services.likec4\`), minus every STANDALONE service directory (\`service.model-unexcluded\` owns that state), minus \`features/\` (a delta carries its own \`specification\` and the directory is transient) — and reports each error that is NOT already present in the map alone, in some per-service project, or in a service-flow project the same run made. A \`.likec4\` in a SUBSYSTEM directory, above every service, is in that set. That difference is exactly the class no per-service grade can see: two services each declaring \`tag req-AUTH\` locally, two models adding the same child id under one element, a broken untagged sibling nobody opted in. All of them are renderer-fatal and all of them were silent. \`locations[0]\` is the file the error is IN, \`details\` carry \`<path>: L<n>: <error>\` 1-based — path, colon, space, then the line, exactly as the message's own head spells it, so an agent splitting on the separator gets the same two halves from either — and the message tail names the failure it actually is — a double declaration, an unresolved reference, or neither. \`subject\` is the service whose directory holds the file, where there is one | declare it once — in \`architecture/landscape.likec4\`, or in the single service that owns it — at the file and line the message names. Never by excluding the directory: that hides the model from the renderer instead (\`service.model-excluded\`) |
+| \`subsystem.view-id-collision\` | a document the root project reads declares a view whose id is one loam GENERATES — \`subsystem_<name>\` into \`architecture/subsystems.likec4\`, or \`service_<id>\` into \`architecture/services.likec4\`. Two reserved prefixes, one code, because the failure is identical: LikeC4 merges every file of a project into one model and view ids are a flat namespace there, so the renderer refuses the WHOLE project and draws nothing — while every other check here stays green. Under \`--all\` the census covers every EXTENDING model's authored view ids as well as the landscape's, because those documents are in the same root project now; a standalone model's are not, since its views live in a project of its own. Only a real collision is reported: a \`subsystem_\`-looking id matching no current subsystem breaks nothing yet and fires on the run after somebody creates it, and a \`service_\`-looking id is reserved only for a service the fleet MAP DRAWS — an unmodelled \`services/<id>/\` mints nothing until an element resolves to it | rename the view in the file the finding names — the message names which file and which prefix. Ids beginning \`subsystem_\` or \`service_\` are loam's to mint; both generated files are written by \`loam subsystem sync\` and are never hand-edited |
 | \`landscape.merge-conflict\` | the fleet map still holds conflict markers — it is two halves of two different maps, and every cross-service check reads it. Checked BEFORE the parse and returns like \`landscape.invalid\`: nothing is concluded from the file, so no \`landscape.service-unmodelled\` fires behind it | resolve it keeping BOTH sides' elements and edges; ten people adopting ten services into one landscape.likec4 in the same week is how it happens. \`loam archive\` refuses on it too (\`merge-failed\`, not overridable with \`--approve\`) |
 | \`landscape.service-unmodelled\` | a \`services/<svc>/\` no element in the landscape resolves to | draw it, or bind an existing element with \`metadata { service '<svc>' }\` — the fleet map is incomplete until you do |
 | \`landscape.service-undocumented\` (warn) | a landscape element with no \`services/<id>/\` | document the service, bind the element to the directory it means, or tag it \`#external\` if it is not ours |
@@ -264,7 +267,6 @@ what lets a feature ship:
 | \`landscape.service-isolated\` (warn) | an element resolves to a \`services/<id>/\` and no edge anywhere in \`architecture/\` touches it, while that service's own \`model.likec4\` declares a call across its boundary. The map draws the service and nothing reaches it, so every cross-service check is vacuous over it — and \`loam validate --service\` cannot see it. Evidence-gated: a service whose model declares no cross-boundary call is silent here, and the adopt brief's \`landscape.touched\` is the only place that state is named. Binary, too: ONE edge closes it, so a map drawing one of five attested calls is silent — the check is touched/untouched, not a set difference, and the calls left undrawn are named nowhere. An \`#external\` element is never the subject, whatever it is bound to; the touched side applies no tag filter — an edge on an \`#external\` element the service owns (a kind-tagged topic, say) still touches it, exactly as the adopt brief's \`landscape.touched\` counts it | draw each attested call as one edge on the element, collapsed to the service, carrying \`metadata { op '<operationId>' }\` for a call or \`publishes\`/\`consumes\` for an event, naming the other party as the map already spells it — never a second element |
 | \`landscape.kind-tag-graded\` | the \`specification\` block declares \`#external\` or \`#platform\` on an element KIND, and at least one element of that kind stands for a real \`services/<id>/\` — bound with \`metadata { service }\`, or titled like one. Since LikeC4 1.59.0 a kind's tags land on every element of it, and loam reads both tags as "not ours, stop grading", so the exemption is silencing the checks for a service of yours; the run would otherwise end on \`landscape.matched\` over a map nothing checked | remove the tag from the kind and write \`#external\` / \`#platform\` on the individual elements that really are foreign — or stop drawing your own services as that kind. A graded tag on a kind whose elements stand for no directory of yours (the \`element topic { #external }\` idiom for the topics inside a broker) is correct and stays silent, and any OTHER tag is safe on any kind — loam does not read it |
 | \`landscape.platform-candidate\` (warn) | an \`#external\` element consumed by three or more services and not tagged \`#platform\` — a hub on its way to making the fleet view unreadable | declare \`tag platform\` in the \`specification\` block and tag the element (LikeC4 refuses an undeclared tag, so both steps are needed): the fleet view then excludes it, and a platform view over \`include * -> element.tag = #platform\` keeps "who depends on it" answerable |
-| \`landscape.datastore-private\` (warn) | a datastore element with exactly one consumer service at fleet level — drawn as a peer, it reads as a system in its own right. Consumers are counted from the map's edges AND from every EXTENDING model's attested outbound calls, so a store whose consuming edges all live in models is graded rather than silent | it is that service's internals: write it inside the element that resolves to that service — the \`extend <fqn> { }\` block of \`services/<id>/model.likec4\` when that model EXTENDS the map, or inside \`<fqn>\` on the map when the map draws that service's containers — and delete the peer. The message names whichever the consumer's model shape allows: a model that declares its own \`specification\` is parsed alone, so \`extend <fqn>\` resolves nothing there and the map is the only placement (migrate the model to the extending shape, or write one when there is none). Either way the two placements give the store the same id, \`<fqn>.<store>\`, and with one consumer either move is free — out of the \`extend\` block onto the map always is, and back into it while no other service's model or map edge names the store, an \`extend\` block being visible to its own service's project alone. Nesting closes no door: loam counts a consumer an EXTENDING model attests, so a second service reaching the same data is \`landscape.datastore-shared\` rather than silence — a consumer whose model stands alone is not counted, its ids being its own file's, so its edge belongs on the map. That second edge resolves only against a store the MAP declares (a per-service project is \`architecture/\` plus one model), so nest it on the map when a second consumer is foreseeable. If another service reaches the same data today, draw its edge and this becomes that warning now |
 | \`landscape.datastore-shared\` (warn) | a datastore consumed by two or more services — the strongest coupling in the fleet, stated rather than inferred. Two shapes: a store drawn as a fleet-level peer, and a store NESTED inside its owner's element that another service reaches — the message adds \` — <owner>'s own store, written as '<store-fqn>'\` for the second, \`<store-fqn>\` being the store's own id, and then says the move is ONE-WAY at this point: the other consumers' edges resolve only against a declaration the MAP holds, so out of the owner's \`extend\` block onto the map is always safe while moving it back INTO the \`extend\` block breaks them (\`c4.invalid\` on that service's model, or \`landscape.invalid\` when the edge is drawn on the map). Consumers are counted from the map's edges AND from every extending model's attested outbound calls | shared means the same DATA: if they read the same tables or keys, keep it drawn and let the warning state the coupling; if they only share a host or cluster (two schemas, two lock paths), model one private store per service and put the blast radius in the runbook |
 | \`usecase.capability-unresolved\` | a \`dynamic view\` tagged \`#cap-<slug>\` whose slug matches no declared capability id, or more than one. The tag spells the id with every character outside \`[A-Za-z0-9_-]\` flattened to \`-\` (that is all a LikeC4 tag name accepts) and that flattening is not injective, so \`payments/refunds\` and \`payments-refunds\` both answer to one tag. Silent while \`architecture/capabilities.yaml\` is absent or invalid, like the rest of that family — the FILE is the capability axis's opt-in, or carried by a flow inside a service's own project (a \`dynamic view\` beside model.likec4), where no capability can be claimed — that arm fires whether or not the vocabulary exists, and the fix is to drop the tag or move the flow to \`architecture/usecases/\` | zero matches: fix the tag, or declare the capability in the fleet vocabulary (the message offers close ids, each already spelled as the tag you would write). More than one: rename one of the colliding ids — nothing in the tag can say which the flow realizes, and a guess files every hop of it under an owner who never claimed it |
 | \`usecase.requirement-unresolved\` | a \`dynamic view\` tagged \`#req-<slug>\` whose slug names no requirement of the capability that view is about. Six failures with six fixes, and the message says which: the view resolves no \`#cap-\` tag (a \`Requirement-ID\` is unique only inside its own document, so the id has no scope), it resolves two (nothing says which document), the capability has no \`capabilities/<id>/spec.md\`, that document declares no requirements yet, it declares none flattening to this slug, or two of its ids flatten to one slug. It suppresses NOTHING: only a RESOLVED claim counts as a promise kept, so a broken tag leaves \`capability.requirement-unrealized\` firing beside it | follow the message. Several \`#req-\` tags on one view are legal and normal — a flow commonly keeps two of a capability's promises |
@@ -286,6 +288,7 @@ intent.md, both modes:
 | \`frontmatter.field-mismatch\` | the doc names a different service/feature than the one it lives under | fix the frontmatter, or move the file |
 | \`frontmatter.status-unknown\` | a status nobody defined (\`verifed\`) | use the documented vocabulary — a typo here reads as unverified forever |
 | \`frontmatter.field-missing\` (warn) | owner, status or the identity field is absent | fill them in |
+| \`frontmatter.owner-mismatch\` (warn) | 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, so the other is a second answer nobody sees. The \`details\` list each file's value. Compares the two files only, never CODEOWNERS | make the two agree; only a person knows which one is current |
 | \`sources.absent\` (warn) | the doc names no sources | nothing ties it to the code, so nothing can tell you when it goes stale |
 | \`sources.path-missing\` | a listed source no longer exists, or is a glob pattern (no longer supported) | the code moved — re-read it and update the doc, do not just fix the path. For a pattern, name files or directories instead |
 | \`sources.path-outside\` | a listed source resolves OUTSIDE the service's repository — an absolute path, a \`..\` escape, or a path that only exists on one machine. loam will not hash bytes beyond the repo boundary, so the tie the entry claims cannot be checked | name the path repo-relative, inside the repository; if the document was really written from another repo's files, it belongs to that repo |
@@ -293,7 +296,7 @@ intent.md, both modes:
 | \`sources.empty\` (warn) | the declared \`sources\` exist but expand to no files at all — an empty directory, or a tree the repository ignores. A digest over nothing reads as current forever | point \`sources\` at the files the document was actually written from; \`loam vouch\` refuses to stamp this state with the same sentence |
 | \`sources.skipped\` (warn) | a path under a listed source was found but NOT hashed: a symlink loam will not follow (its target is outside the repository, dangling, or not a file or directory) — the digest cannot go stale over bytes it never read | not yours to close by editing the document: either the symlink should not be under a listed source, or \`sources\` should name the real path. Report it |
 | \`sources.unvouched\` (warn) | \`sources\` with no \`sources_digest\` — nobody ever stamped it | leave it: vouching is a human's reading, not yours |
-| \`sources.unwalked\` (warn) | \`sources\` leaves whole top-level paths of the service repo untouched — the \`details\` name them, measured against the files git tracks. The one completeness signal loam can compute: every other check compares the documents with each other, and a corpus agrees with itself perfectly while describing a third of a service. Silent where git cannot answer (not a repository, not installed) | open them. Each one is either a part of the service nobody read — go back to the walk \`loam adopt\` printed — or something this document legitimately does not owe, and then say which and why in the hand-back. Do NOT add paths to \`sources\` that you did not read: the list is a record of what was opened, and padding it destroys the only tie the document has to the code |
+| \`sources.unwalked\` (warn) | \`sources\` leaves whole top-level paths of the service repo untouched — the \`details\` name them, measured against the files git tracks — minus loam's own (\`loam.json\` and the agent files it recorded) and \`.gitignore\`, which no document owes a reading of. The one completeness signal loam can compute: every other check compares the documents with each other, and a corpus agrees with itself perfectly while describing a third of a service. Silent where git cannot answer (not a repository, not installed) | open them. Each one is either a part of the service nobody read — go back to the walk \`loam adopt\` printed — or something this document legitimately does not owe, and then say which and why in the hand-back. Do NOT add paths to \`sources\` that you did not read: the list is a record of what was opened, and padding it destroys the only tie the document has to the code |
 | \`content.stale\` (warn) | the spec's body changed since it was vouched — \`status: verified\` is standing over words nobody has read. Unlike \`sources.*\` it needs no service repo, so it fires from the docs repo too | if you edited the doc, that is the point: report it and ask a human to re-vouch. Never revert the doc or touch the digest just to silence it |
 | \`sources.sampled-vouch\` (warn) | a person vouched after reading a recorded SAMPLE of the document — the stamp carries \`vouch_scope: sampled k/n seed=…\`, so \`status: verified\` stands over sections nobody read. The status and the \`vouched\` rung are unchanged and correct; this is what says the reading behind them was partial. A \`vouch_scope\` that does not decode fires it too, deliberately: an unreadable scope must never read as a full vouch. Doc-side, so it fires from the docs repo as well | not yours to clear. NEVER edit the document, and never touch or delete the \`vouch_scope\` field, to silence it — deleting it would forge a full vouch out of a partial one. A human runs a full \`loam vouch --service <id>\` (no \`--sample\`) once they have read the rest, which removes the field; \`loam vouch --pack --service <id>\` lists exactly what that sample left unread |
 | \`sources.resolved\` (ok) | every listed source still exists in the service repo | nothing — it is the confirmation |
@@ -310,13 +313,13 @@ contract too):
 | code | what it means | what to do |
 |---|---|---|
 | \`living.requirement-outside-requirements\` | the LIVING spec holds a requirement outside \`## Requirements\`, and the merge rewrites only that section — it would land in the file twice | re-home the requirement under \`## Requirements\`, then re-run; \`--approve\` does not override this |
-| \`openapi.op-modified\` (warn) | the feature redefines an operation the living OpenAPI already has — the merge overwrites the living definition wholesale | make sure the redefinition is intended; if not, align the feature's openapi.yaml with the living one |
+| \`openapi.op-modified\` (warn) | the feature redefines an operation the living OpenAPI already has — the merge overwrites the living definition wholesale. The message ends with whether the CURRENT fleet names the operation, and \`details\` lists who does — landscape edges, other services' living requirements, use-case hops — then any consumer that could not be checked; the same scan \`loam diff\` runs. Whether the change breaks them is not graded | make sure the redefinition is intended and safe for every consumer listed (\`oasdiff breaking\` on the two contract states tells a breaking change from an additive one); if not, align the feature's openapi.yaml with the living one |
 | \`openapi.path-item-modified\` (warn) | the delta redefines a PATH-level key (\`parameters\`, \`servers\`, \`summary\`, an \`x-\`) the living OpenAPI already has — the overwrite applies to EVERY operation on that path, including ones this feature never mentions | keep path-level keys out of the delta unless changing them for every operation on the path is the intent |
 | \`service.no-model\` (warn) | the archive creates \`services/<id>/\` but nothing writes its \`model.likec4\` | run \`loam adopt --service <id>\` after the archive lands, or the new service ships without a C4 center and \`validate --all\` grades it incomplete |
 | \`openapi.component-modified\` (warn) | a component this delta declares — whether the merged operations reference it or the components ARE the delta — already exists in the living OpenAPI with different content, and the merge copies the feature's version over it wholesale | make sure the redefinition is intended; if not, align the feature's component with the living one |
 | \`openapi.ref-unresolved\` | a \`$ref\` reachable from the merged operations or a merged component resolves in neither the feature's OpenAPI nor the living one — the merge would write a dangling reference | define the missing component or fix the ref; \`--approve\` merges the dangling reference anyway. External refs (not starting \`#/\`) are never checked |
 | \`openapi.remove-marker-path-level\` | an \`x-loam-remove: true\` written at PATH level, beside the methods instead of inside the operation being retired — it names no operation, so it retires nothing, and it is not a contract key either | move the marker inside the operation (with its \`operationId\`), or delete it. The merge is safe either way — a feature-only key is never published into the living contract — but the removal you asked for will not happen |
-| \`asyncapi.message-modified\` (warn) | the delta redefines a \`components.messages\` slot the living AsyncAPI already has — the merge overwrites the living message wholesale | make sure the redefinition is intended; if not, align the feature's asyncapi.yaml with the living one, then \`loam rebase\` so the restatement classifies as a quote |
+| \`asyncapi.message-modified\` (warn) | the delta redefines a \`components.messages\` slot the living AsyncAPI already has — the merge overwrites the living message wholesale. The message ends with whether the CURRENT fleet consumes it, and \`details\` lists who does — \`consumes\` edges, other services' \`Consumes:\` lines, use-case hops — then any consumer that could not be checked; the same scan \`loam diff\` runs. Whether the change breaks them is not graded | make sure the redefinition is intended and safe for every consumer listed; if not, align the feature's asyncapi.yaml with the living one, then \`loam rebase\` so the restatement classifies as a quote |
 | \`asyncapi.channel-modified\` (warn) | the delta redefines a \`channels\` slot the living AsyncAPI already has — the merge overwrites it wholesale, inline channel messages included (they are channel interior, never slots of their own) | make sure the redefinition is intended; if not, align the feature's channel with the living one |
 | \`asyncapi.operation-modified\` (warn) | the delta redefines an \`operations\` slot the living AsyncAPI already has — the merge overwrites it wholesale | make sure the redefinition is intended; if not, align the feature's operation with the living one |
 | \`asyncapi.component-modified\` (warn) | the delta declares a component SURFACE outside \`components.messages\` — a \`components.schemas\` entry, a security scheme — that the living AsyncAPI already has with different content, and the merge copies the feature's version over it wholesale | make sure the redefinition is intended; if not, align the feature's component with the living one, then \`loam rebase\` so the restatement classifies as a quote |