@ybotok/loam 0.1.0-beta.3 → 0.2.0-alpha.13

package/dist/core/agent/workflows/reference/reference.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"reference.js","sourceRoot":"","sources":["../../../../../src/core/agent/workflows/reference/reference.ts"],"names":[],"mappings":"AAiEA,OAAO,EAAE,cAAc,EAAE,MAAM,gBAAgB,CAAC;AAChD,OAAO,EAAE,UAAU,EAAE,MAAM,YAAY,CAAC;AACxC,OAAO,EAAE,eAAe,EAAE,MAAM,iBAAiB,CAAC;AAClD,OAAO,EAAE,YAAY,EAAE,MAAM,sBAAsB,CAAC;AACpD,OAAO,EAAE,UAAU,EAAE,MAAM,YAAY,CAAC;AAExC;;;;;GAKG;AACH,MAAM,CAAC,MAAM,UAAU,GAAqB;IAC1C,UAAU;IACV,UAAU;IACV,cAAc;IACd,eAAe;IACf,YAAY;CACb,CAAC","sourcesContent":["/**\n * Why the reference pages exist, what decided which content became one, and the\n * list itself.\n *\n * THE MEASUREMENT. AGENTS.md is auto-loaded from the working directory by every\n * agents.md-aware host, on every session, and `loam init` writes it once and\n * never refreshes it. It had reached 109,399 bytes. Codex truncates the\n * AGENTS.md chain at 32,768 bytes and Windsurf caps a workspace rule file at\n * 12,000 characters — both silently, with no error and no way for the reader to\n * tell which half it was holding. Roughly seventy percent of the document was\n * being dropped on those two hosts, and which seventy percent depended on the\n * host rather than on what the reader needed.\n *\n * THE SPLIT RULE, which is not \"move the big parts\". Two kinds of content were\n * mixed in one file:\n *\n *  - what a reader needs to FORM a question — the layout, the cycle, which\n *    element is which service, what gates and what only advises, what the words\n *    mean. Without it an agent cannot ask anything, so it cannot be behind a\n *    command it does not know to run. That stays in AGENTS.md;\n *  - what a reader CONSULTS at a moment it can name — the grammars for writing\n *    one document, the inventory of what a command can report, the done-check's\n *    channels. The moment is nameable (\"I am writing an arch.spec.md\", \"a run\n *    reported something\"), so the page can be fetched then, and paying for it on\n *    every invocation of every session bought nothing.\n *\n * That rule is why the binding rule — which element IS which service — stayed\n * in AGENTS.md while the rest of the ID spine left (it is ORIENTATION's\n * `## The identity rule` in ../../agents-md.ts now, condensed from the section\n * that used to stay behind), and why the per-invocation code inventory left\n * while the facts about the `--json` envelope stayed. Size followed from the\n * rule; it did not drive it.\n *\n * WHAT A PAGE COSTS AND WHAT IT BUYS. A page printed by the binary describes\n * the loam you are about to run, not the one that scaffolded the repository —\n * which is strictly better than a file `loam init` writes once and never\n * refreshes, and is why `agents.stale` exists at all. What it costs is\n * discoverability: a reference nobody can find is content deleted with extra\n * steps. Three things pay that back, and all three are asserted rather than\n * hoped for — AGENTS.md's own \"Reference pages\" section names each page\n * with the exact command (test/agents.test.ts), bare `loam instructions` lists\n * them beside the workflows (test/instructions.test.ts), and every stable code\n * that left is still in the corpus test/codes-drift.test.ts reads, because\n * {@link REFERENCES} feeds `PROTOCOLS`.\n *\n * WHAT A PAGE IS NOT. It is not a workflow. It has no steps, takes no\n * arguments, and `loam init` writes NO file for it — ../../protocol.ts feeds\n * this list to `PROTOCOLS` and `placeholderProblems` and to nothing else, so\n * `SLASH_COMMANDS` and `plannedCommandFiles` never see it and no repository\n * gains a generated artifact. Four pages are four more files in every repo loam\n * touches, and the whole point of the move was to stop shipping bytes nobody\n * asked for.\n *\n * THE MOVE WAS A MOVE. Every page's text is its AGENTS.md section verbatim.\n * Nothing was rewritten on the way, because a paraphrase is a second copy that\n * can drift — and removing one of those is what this whole change is for.\n *\n * THE FIFTH PAGE WAS NEVER A SECTION. `loam-drawing` (./drawing/drawing.ts)\n * was written as a page from the start: how to draw the map so that a person\n * can read it is consulted at the moment an edge or a view is drawn, which is\n * the split rule above, and no AGENTS.md section ever held it. It came from a\n * real fleet whose documents all validated while every picture of it was\n * unreadable. The page carries the rest of that story.\n */\nimport type { CommandContent } from \"../../contract.js\";\nimport { LOAM_AUTHORING } from \"./authoring.js\";\nimport { LOAM_CODES } from \"./codes.js\";\nimport { LOAM_DONE_CHECK } from \"./done-check.js\";\nimport { LOAM_DRAWING } from \"./drawing/drawing.js\";\nimport { LOAM_SPINE } from \"./spine.js\";\n\n/**\n * The five pages, in the order AGENTS.md's own index names them. The first four\n * stand in the order their sections stood in the document they left, so a\n * reader who knew the file finds them where they were. The drawing page comes\n * last because it never stood there.\n */\nexport const REFERENCES: CommandContent[] = [\n  LOAM_CODES,\n  LOAM_SPINE,\n  LOAM_AUTHORING,\n  LOAM_DONE_CHECK,\n  LOAM_DRAWING,\n];\n"]}

package/dist/core/agent/workflows/reference/spine.js

@@ -0,0 +1,338 @@
+export const LOAM_SPINE = {
+    name: "loam-spine",
+    description: "Reference: the ID spine — every join between the artifacts, and the baseline pins",
+    // A reference page takes no arguments: it is one document, printed whole.
+    // The empty hint is what `loam instructions` prints beside the name, and an
+    // invented one ("<none>") would read as an argument somebody could pass.
+    argumentHint: "",
+    purpose: "The exact joins the artifacts are held together by — operationId, message name, `Covers:`, `Requires:`, `Capability:`/`Realizes:` — and the `Based-On:` pins that stop two features in flight reverting each other.",
+    invocation: "loam instructions loam-spine",
+    placeholders: [],
+    spine: [
+        "The ID spine",
+        "The requirement baseline — `Based-On:`",
+        "Drawing a shared broker",
+        "A message produced outside the fleet",
+    ],
+    body: `The ID spine: how the artifacts join, and what pins a change to the version it was written against.
+
+## The ID spine
+
+The spine is a family of exact joins, not one magic id: feature tag; service
+binding; synchronous operation; asynchronous message; architecture coverage;
+authorization permission. Three artifacts describe the same synchronous call in
+three languages. They are joined by the **operationId**, and that join is what
+\`loam validate\` checks:
+
+- architecture — a C4 edge names the operation it calls:
+  \`checkoutWeb -> paymentService 'Calls authorizePayment' { metadata { op 'authorizePayment' } }\`
+- behaviour — a requirement declares the operations it governs:
+  \`Operations: authorizePayment\`
+- contract — the provider's \`openapi.yaml\` defines it:
+  \`operationId: authorizePayment\`
+
+Spell it identically in all three places. A mismatch is an error, not a warning:
+an edge calling an operation nobody defines is a broken contract between services.
+
+Features are joined the same way: a delta's new elements and edges carry the
+feature id as a LikeC4 tag (\`#FEAT-101\`), and that tag is exactly what
+\`loam archive\` folds into the living landscape. Untagged elements in a delta are
+context for the diagram, not changes.
+
+The other joins use the same discipline:
+
+- \`metadata { publishes|consumes 'message' }\` on an edge ↔
+  \`Publishes:\`/\`Consumes:\` in a requirement ↔ the AsyncAPI 3 message name;
+- \`Covers:\` in an architecture requirement ↔ a C4 element/edge or
+  \`alert:<id>\` / \`sli:<id>\` from health.yaml;
+- \`Requires: <subject>/<permission>\` in either requirement file ↔ the fleet
+  declaration in \`architecture/permissions.yaml\`;
+- \`Capability:\` in either requirement file ↔ a declared id in
+  \`architecture/capabilities.yaml\`. A LIST, comma-separated — the relation is
+  many-to-many in both directions.
+
+The permissions file is opt-in: a fleet with no \`Requires:\` line owes none.
+Once a requirement names a permission, an undeclared pair is
+\`permissions.unknown\` (error). An unreadable vocabulary is
+\`permissions.invalid\`; a declaration nothing requires is
+\`permissions.unenforced\` (warn). The subject is what the permission is checked
+ON (user, profile, service), not necessarily the caller. \`owned_by\` and
+\`enforced_by\` are explanatory and are not resolved against services; this is
+a checked document join, not proof that the identity provider implements it.
+
+The capability axis opts in the OTHER way: the FILES are the opt-in, not the
+line. A fleet with neither \`architecture/capabilities.yaml\` nor a
+\`capabilities/\` directory gets no capability findings at all, however many
+\`Capability:\` lines its requirements already carry.
+
+A capability may be declared on either side, and the vocabulary is the UNION.
+A name alone is a line in \`architecture/capabilities.yaml\` —
+\`capabilities: {<id>: {description, owner}}\`, nested ids such as
+\`payments/refunds\` kept as one flat key. A name with prose behind it gets a
+document instead: \`capabilities/<id>/spec.md\`, the AUTHORED business tree,
+one directory per capability with nesting spelled by the tree
+(\`capabilities/payments/refunds/spec.md\`). The directory is the list — there
+is no manifest — and its existence is what opts the fleet in, so \`loam init\`
+does not scaffold it. A directory holding neither the document nor a
+capability beneath it is \`capability.doc-missing\` (warn).
+
+The document carries narrative and then \`## Requirements\`, in the same
+grammar every spec.md uses, with two rules of its own. Every requirement needs
+a \`Requirement-ID:\` — these documents outlive the services that realize them,
+so identity is the line and not the heading; without one it is
+\`capability.requirement-unidentified\` (error). And a capability requirement
+must be observable OUTSIDE the fleet: \`Operations:\`, \`Covers:\`,
+\`Publishes:\` and \`Consumes:\` all resolve against one service's own contract,
+so carrying any of them is \`capability.requirement-service-scoped\` (error) —
+write it in that service's spec.md instead. Naming no service is an authoring
+rule that PR review holds, not one loam checks: matching service names in prose
+would be a heuristic, and loam does not guess. The axis's own two joins are
+refused here as well (\`capability.requirement-inert-join\`, error): they point
+INTO the tree, so nothing reads them written inside it.
+
+A FEATURE changes a capability document with a delta, not by editing it:
+\`features/<FEAT>/capabilities/<id>/spec.md\`, the same
+\`## ADDED|MODIFIED|REMOVED Requirements\` grammar the service deltas use, the
+same nesting (\`features/<FEAT>/capabilities/payments/refunds/\`), the same
+\`Based-On:\` pins, and the same \`delta.*\` refusals with the capability id as
+the subject. \`scaffold.placeholder\` reads it too, so an unedited template
+heading refuses the archive here as it does in a spec delta, and
+\`capability.doc-missing\` (warn) names a directory in it that holds no
+\`spec.md\` — an empty one is not a delta, so the merge would carry nothing.
+\`loam archive\` merges it into the living document in the same
+transaction as the service merge, creating \`capabilities/<id>/spec.md\` — and
+so the whole tree — when this is the first feature to mention it. Only what
+the delta marks as the document's own comes across: its H1 as the title
+(unless it names the feature or calls itself a delta — then the title is the
+id), its \`## Purpose\` section as the narrative, and a line linking back to the
+archived delta for everything else, because loam merges requirements and never
+prose; after that the narrative is yours to edit in place. The document's three rules above are
+graded on the delta BEFORE the merge, so a capability requirement filed at the
+wrong altitude is refused while you still hold it. Editing the living document
+directly is still legal; the delta is what makes two features touching one
+promise collide loudly instead of silently. \`loam new <FEAT> --capability <id>\`
+scaffolds that delta, and \`loam show <FEAT>\` and \`loam delta <FEAT>\` list the
+promises a feature changes — a capability delta names no service, so without
+those two a business-only feature reads as a feature carrying nothing.
+
+A service requirement says which promise it serves with \`Realizes:\`, entries
+spelled \`<capability-id>#<Requirement-ID>\`. This is the join the tree exists
+for, and it is NOT the same claim as \`Capability:\` beside it — that names a
+theme, this names one promise, and a requirement commonly carries both. The
+capability half of an entry is what makes the target addressable, since a
+\`Requirement-ID\` is unique only inside its own document; the separator is the
+LAST \`#\`, because the requirement half's grammar excludes one and the
+capability half's does not. Written by whoever implements the requirement,
+never by the analyst — a business document must not be edited every time the
+fleet rearranges which service carries which part.
+
+Both directions are graded. An entry naming no capability requirement is
+\`capability.realizes-unknown\` (error; in a feature delta it gates
+\`loam archive\`, \`--approve\`-overridable), and its message says which of the
+five failures happened — malformed entry, undeclared capability, declared but
+undocumented, document with no requirements, or an id that document does not
+declare. A capability requirement nothing keeps is
+\`capability.requirement-unrealized\` (warn, one per requirement): it never
+gates, because writing the business document ahead of the fleet is the intended
+use. \`loam list capabilities --json\` carries the whole join — each capability's
+requirements, and what realizes each one.
+
+\`Realizes:\` is not the only way to keep a promise, and for a criterion that
+CROSSES services it is not enough: "I enter a login and a password and I am in"
+belongs to no single service's spec, because each promises only its own part. A
+USE CASE can carry it, because it IS the hop sequence. So a \`dynamic view\`
+already tagged \`#cap-<slug>\` may carry \`#req-<slug>\` as well, naming one of
+that capability's requirements — the architect's answer to the analyst's
+promise, graded by the same four \`usecase.*\` codes down to the operation. The
+second tag is SCOPED by the first: a \`Requirement-ID\` is unique only inside its
+own document, so a \`#req-\` tag on a view that resolves no capability, or two, is
+\`usecase.requirement-unresolved\` (error) rather than a guess. Several \`#req-\`
+tags on one view are legal — a flow commonly keeps two promises. Both tags spell
+their id with every character outside \`[A-Za-z0-9_-]\` flattened to \`-\`,
+because that is all a LikeC4 tag name accepts.
+
+Against that vocabulary an undeclared name is \`capability.unknown\` (error; in
+a feature delta it gates \`loam archive\`, \`--approve\`-overridable), an
+unreadable \`capabilities.yaml\` is \`capability.invalid\` exactly once per run
+with every grade that resolves against the vocabulary suspended behind it, and
+a declared capability no living requirement realizes is
+\`capability.unrealized\` (warn, one per capability). The fleet total is
+readable: \`loam list capabilities\` reports each capability's realizing
+requirements, their services and the draft/verified split, and
+\`loam explore --capability <id>\` seeds an exploration from the realizing
+services.
+
+## The requirement baseline — \`Based-On:\`
+
+A MODIFIED requirement carries its FULL new text, not a diff, so archive does not
+merge your wording into the living one — it REPLACES it. When two features rewrite
+the same requirement, the loser loses everything they wrote, scenarios and all.
+
+\`loam validate\` names the other feature while both are in flight
+(\`delta.modified-conflict\`), but that warning cannot see the case that actually
+happens: the first feature archives, stops being an active feature, the second
+revalidates GREEN, and its archive lands text written against a document that no
+longer exists — \`+0 ~1 -0\`, exit 0, nobody told.
+
+So a MODIFIED or REMOVED requirement pins the living version it was written
+against, directly under its identity:
+
+\`\`\`markdown
+### Requirement: Cancel an order
+Requirement-ID: REQ-042
+Based-On: 3bcc7a40f2b23ff3
+\`\`\`
+
+You do not compute that value — \`loam rebase FEAT-101\` writes it, for every
+MODIFIED/REMOVED requirement in the feature, from the living text as it stands
+right now. Run it when you finish authoring a delta, and again after you resolve
+a collision. Archive refuses on a stale pin (\`delta.baseline-stale\`) and says
+both digests.
+
+**Restamping is not resolving.** A pin claims "I read this version". If
+\`loam rebase\` reports a requirement as moved, re-read the living requirement and
+fold in what you still mean BEFORE you ship — otherwise you have re-pinned to a
+document you never read, and archive will merge your text over theirs with
+loam's blessing. There is no automatic three-way merge and there will not be one:
+requirement prose does not merge, people do.
+
+A delta adopted from OpenSpec has no such line and gets a warning
+(\`delta.baseline-missing\`) — one that GATES the archive: unpinned is exactly
+the shape that reverts someone else's landed change at exit 0. A migrated
+corpus is not stranded by this: \`loam rebase <FEAT>\` pins every delta in one
+command, and a human's \`--approve\` archives unpinned when the loss is meant.
+
+### The same pin on the contract axis
+
+A feature's \`openapi.yaml\` is a self-contained document holding ONLY what the
+feature adds, changes or removes — not a copy of the living contract. The merge
+walks only the paths and methods the delta spells: an operation you leave out
+stays exactly as the living contract has it, a local \`$ref\`
+(\`#/components/schemas/Order\`) resolves into the living document, and a new
+operation has no living version to pin — an add-only delta needs no rebase.
+
+What the merge does upsert is every operation the document DOES spell. So an
+operation you quote without changing it — copied for context, or a whole
+contract pasted in — is a collision waiting for someone else's edit: two
+features over one service, each quoting the operation the other edits, destroy
+each other, and the second to archive pushes its authoring-time copy back over
+whatever landed in between. Quote nothing you do not change. Each quote costs a
+pin, and a parallel feature that REMOVES the quoted operation makes it worse
+either way: pinned, the quote is \`openapi.baseline-invalid\`, an error that
+blocks your archive, and \`openapi.op-revived\` beside it; unpinned, it is
+\`openapi.op-revived\` alone — a warning that gates, because the merge would
+read the dead operation as a new one and put it back (\`asyncapi.slot-revived\`
+is the same finding on a channel, operation or message slot). A parallel
+feature that MOVES the operation to another address does the same to a quote
+of the old one, which archived would answer the operationId at both. The fix
+for both is to delete the quote. Keep it only when the feature brings a
+retired operation back ON PURPOSE: then drop any pin, and a human archives
+with \`--approve\`. \`loam rebase\` never pins a retired operation as new —
+nothing lives at its slot, so there is no version to pin — and prints the same
+finding (\`revived[]\` in \`--json\`), so the decision stays with you. It judges
+the delta as it will write it, pins included: a quote of an address another
+operation lives at now — one a move vacated, since re-occupied — IS repinned,
+over the operation living there, which makes it an edit the merge would write;
+the revival that edit makes is reported by that rebase (or its \`--dry-run\`),
+not first by the next validate. The check reads the removal
+markers of the features under \`features/archive/\` — a removal made by
+hand-editing a living contract is invisible to it.
+
+The guard against that collision, for every living operation the delta does
+spell, is a pin — a vendor extension beside \`x-loam-remove\`:
+
+\`\`\`yaml
+paths:
+  /orders/{id}/cancel:
+    post:
+      operationId: cancelOrder
+      x-loam-based-on: 86feabe621ed887d
+\`\`\`
+
+\`loam rebase\` writes one on every operation in the delta the living contract
+already holds, pinned to the living version; what the feature adds gets none.
+That is what lets the merge tell a QUOTE from an EDIT:
+
+- pin equals the operation's own content → you quoted it → **the merge skips it
+  entirely** and the living contract keeps whatever it holds. Archive prints
+  \`· quotes …\` so the plan never silently writes less than your delta spells.
+- pin equals the living operation → you edited it, nobody else did → merged.
+- pin matches neither → you edited it AND somebody landed a change to it →
+  \`openapi.baseline-stale\`, refused.
+
+The two surfaces an in-operation key cannot reach — path-level keys
+(\`parameters\`, \`servers\`, \`summary\`, \`x-*\`) and every
+\`components/<kind>/<name>\` — are pinned the same way through one root record,
+\`x-loam-baselines\`, which \`loam rebase\` also writes and the merge strips: a
+quoted key or component is skipped, an edited one is written and warned as
+\`openapi.path-item-modified\` / \`openapi.component-modified\`. A new component
+is copied in when something the merge writes references it; a living one you
+only \`$ref\` needs no copy in the delta at all. Removal markers carry no pin;
+\`openapi.remove-target-mismatch\` is what guards those.
+
+## Drawing a shared broker
+
+A broker drawn as ONE element is the node every service in the fleet points at,
+and any view over it is a star nobody can read. Nothing in loam catches this —
+loam parses the model and renders no view, so the map can be perfectly valid and
+completely illegible. Two habits keep it readable, and both are cheap only
+before the fleet is drawn:
+
+**Model the topic, not the broker.** Nest a topic per channel inside the broker's
+element and point the edges at it — \`paymentService -> kafka.paymentEvents\`, not
+\`paymentService -> kafka\`. One hub of degree sixty becomes twelve of degree
+five, and it is the truer model besides: what a producer and a consumer share is
+the topic, never the broker. Every check joins the same way, because an edge into
+a nested element resolves to the element that owns it. Declare the kind once —
+
+    specification {
+      element topic {
+        style { shape queue }
+      }
+    }
+
+The KIND is what does the work: since 2026-09-07 loam reads \`database\`, \`queue\`,
+\`topic\`, \`cache\` and \`bucket\` as infrastructure rather than as candidate
+services, so a topic drawn this way is out of the service census and nobody is
+asked for a \`services/payment.events/\` (measured: the same element spelled
+\`container\` earns \`landscape.service-undocumented\`, spelled \`topic\` it earns
+nothing). This used to need \`#external\` ON THE KIND as a workaround, because
+**LikeC4 does not inherit tags** and a topic nested inside an \`#external\` broker
+is not external itself. That workaround is no longer owed. Tag the kind
+\`#external\` if you want the topics out of the fleet VIEW as well — that is what
+the next paragraph's \`exclude\` reads, and it is a rendering choice now rather
+than a way to silence a check.
+
+**Scope the views.** \`exclude element.tag = #external\` keeps the fleet overview to
+the calls between our own services; a second view over the broker draws the event
+spine on its own. Views are LikeC4's and loam computes none, so this costs loam
+nothing and is worth doing anyway — an \`include *\` over the whole fleet map is
+also the one view whose computation takes minutes rather than milliseconds. The
+scaffolded landscape applies the same pruning to ubiquitous infrastructure with
+\`#platform\`: the fleet view excludes it, and the platform view's
+\`include * -> element.tag = #platform\` (the relationship form — the obvious
+spelling draws boxes with no edges) keeps "who depends on it" answerable.
+
+## A message produced outside the fleet
+
+A platform service that is not ours — a config service, an auth broker —
+produces messages our services consume, and no \`services/<id>/\` will ever hold
+its contract. Declare the production on the landscape, where the element
+already says \`#external\`:
+
+    externalConfig = softwareSystem 'external-config' {
+      #external
+    }
+    externalConfig -> kafka.configTopic 'publishes config refreshes' {
+      metadata { publishes 'config.ConfigRefreshed' }
+    }
+
+\`spine.message-unproduced\` then stops firing — the message HAS a producer,
+outside the fleet — and the contract question moves to the one file that can
+answer it: the consuming service's own asyncapi.yaml. While that file declares
+no shape for the message, \`spine.message-external\` (warn) says so; once the
+consumer declares the payload, the axis is quiet. A truthful map and a green
+build no longer exclude each other, which is the exact choice this used to force.
+`,
+};
+//# sourceMappingURL=spine.js.map

package/dist/core/agent/workflows/reference/spine.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"spine.js","sourceRoot":"","sources":["../../../../../src/core/agent/workflows/reference/spine.ts"],"names":[],"mappings":"AAsBA,MAAM,CAAC,MAAM,UAAU,GAAmB;IACxC,IAAI,EAAE,YAAY;IAClB,WAAW,EAAE,mFAAmF;IAChG,0EAA0E;IAC1E,4EAA4E;IAC5E,yEAAyE;IACzE,YAAY,EAAE,EAAE;IAChB,OAAO,EACL,qNAAqN;IACvN,UAAU,EAAE,8BAA8B;IAC1C,YAAY,EAAE,EAAE;IAChB,KAAK,EAAE;QACL,cAAc;QACd,wCAAwC;QACxC,yBAAyB;QACzB,sCAAsC;KACvC;IACD,IAAI,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+TP;CACA,CAAC","sourcesContent":["/**\n * The `loam-spine` reference page: how the artifacts JOIN.\n *\n * Operation and message ids, coverage and permission references, the\n * capability tree and its `Realizes:` join, the requirement baseline pins\n * (`Based-On:` / `x-loam-based-on`), how to draw a shared broker, and how to\n * declare a message produced outside the fleet.\n *\n * This is the grammar a reader consults while writing ONE document, which is\n * why it is a printed page rather than a section of AGENTS.md: it is consulted\n * at a moment you can name, and paying for it on every invocation of every\n * session bought nothing. Which element IS which service deliberately stayed\n * in AGENTS.md — today as ORIENTATION's `## The identity rule` in\n * ../../agents-md.ts — because an agent cannot read the landscape at all\n * without it, so it is orientation rather than reference.\n *\n * The text is the AGENTS.md section verbatim; nothing was rewritten to move\n * it, so a cross-reference from the remaining file still names the same\n * headings. See ./reference.ts for why these four pages exist.\n */\nimport type { CommandContent } from \"../../contract.js\";\n\nexport const LOAM_SPINE: CommandContent = {\n  name: \"loam-spine\",\n  description: \"Reference: the ID spine — every join between the artifacts, and the baseline pins\",\n  // A reference page takes no arguments: it is one document, printed whole.\n  // The empty hint is what `loam instructions` prints beside the name, and an\n  // invented one (\"<none>\") would read as an argument somebody could pass.\n  argumentHint: \"\",\n  purpose:\n    \"The exact joins the artifacts are held together by — operationId, message name, `Covers:`, `Requires:`, `Capability:`/`Realizes:` — and the `Based-On:` pins that stop two features in flight reverting each other.\",\n  invocation: \"loam instructions loam-spine\",\n  placeholders: [],\n  spine: [\n    \"The ID spine\",\n    \"The requirement baseline — `Based-On:`\",\n    \"Drawing a shared broker\",\n    \"A message produced outside the fleet\",\n  ],\n  body: `The ID spine: how the artifacts join, and what pins a change to the version it was written against.\n\n## The ID spine\n\nThe spine is a family of exact joins, not one magic id: feature tag; service\nbinding; synchronous operation; asynchronous message; architecture coverage;\nauthorization permission. Three artifacts describe the same synchronous call in\nthree languages. They are joined by the **operationId**, and that join is what\n\\`loam validate\\` checks:\n\n- architecture — a C4 edge names the operation it calls:\n  \\`checkoutWeb -> paymentService 'Calls authorizePayment' { metadata { op 'authorizePayment' } }\\`\n- behaviour — a requirement declares the operations it governs:\n  \\`Operations: authorizePayment\\`\n- contract — the provider's \\`openapi.yaml\\` defines it:\n  \\`operationId: authorizePayment\\`\n\nSpell it identically in all three places. A mismatch is an error, not a warning:\nan edge calling an operation nobody defines is a broken contract between services.\n\nFeatures are joined the same way: a delta's new elements and edges carry the\nfeature id as a LikeC4 tag (\\`#FEAT-101\\`), and that tag is exactly what\n\\`loam archive\\` folds into the living landscape. Untagged elements in a delta are\ncontext for the diagram, not changes.\n\nThe other joins use the same discipline:\n\n- \\`metadata { publishes|consumes 'message' }\\` on an edge ↔\n  \\`Publishes:\\`/\\`Consumes:\\` in a requirement ↔ the AsyncAPI 3 message name;\n- \\`Covers:\\` in an architecture requirement ↔ a C4 element/edge or\n  \\`alert:<id>\\` / \\`sli:<id>\\` from health.yaml;\n- \\`Requires: <subject>/<permission>\\` in either requirement file ↔ the fleet\n  declaration in \\`architecture/permissions.yaml\\`;\n- \\`Capability:\\` in either requirement file ↔ a declared id in\n  \\`architecture/capabilities.yaml\\`. A LIST, comma-separated — the relation is\n  many-to-many in both directions.\n\nThe permissions file is opt-in: a fleet with no \\`Requires:\\` line owes none.\nOnce a requirement names a permission, an undeclared pair is\n\\`permissions.unknown\\` (error). An unreadable vocabulary is\n\\`permissions.invalid\\`; a declaration nothing requires is\n\\`permissions.unenforced\\` (warn). The subject is what the permission is checked\nON (user, profile, service), not necessarily the caller. \\`owned_by\\` and\n\\`enforced_by\\` are explanatory and are not resolved against services; this is\na checked document join, not proof that the identity provider implements it.\n\nThe capability axis opts in the OTHER way: the FILES are the opt-in, not the\nline. A fleet with neither \\`architecture/capabilities.yaml\\` nor a\n\\`capabilities/\\` directory gets no capability findings at all, however many\n\\`Capability:\\` lines its requirements already carry.\n\nA capability may be declared on either side, and the vocabulary is the UNION.\nA name alone is a line in \\`architecture/capabilities.yaml\\` —\n\\`capabilities: {<id>: {description, owner}}\\`, nested ids such as\n\\`payments/refunds\\` kept as one flat key. A name with prose behind it gets a\ndocument instead: \\`capabilities/<id>/spec.md\\`, the AUTHORED business tree,\none directory per capability with nesting spelled by the tree\n(\\`capabilities/payments/refunds/spec.md\\`). The directory is the list — there\nis no manifest — and its existence is what opts the fleet in, so \\`loam init\\`\ndoes not scaffold it. A directory holding neither the document nor a\ncapability beneath it is \\`capability.doc-missing\\` (warn).\n\nThe document carries narrative and then \\`## Requirements\\`, in the same\ngrammar every spec.md uses, with two rules of its own. Every requirement needs\na \\`Requirement-ID:\\` — these documents outlive the services that realize them,\nso identity is the line and not the heading; without one it is\n\\`capability.requirement-unidentified\\` (error). And a capability requirement\nmust be observable OUTSIDE the fleet: \\`Operations:\\`, \\`Covers:\\`,\n\\`Publishes:\\` and \\`Consumes:\\` all resolve against one service's own contract,\nso carrying any of them is \\`capability.requirement-service-scoped\\` (error) —\nwrite it in that service's spec.md instead. Naming no service is an authoring\nrule that PR review holds, not one loam checks: matching service names in prose\nwould be a heuristic, and loam does not guess. The axis's own two joins are\nrefused here as well (\\`capability.requirement-inert-join\\`, error): they point\nINTO the tree, so nothing reads them written inside it.\n\nA FEATURE changes a capability document with a delta, not by editing it:\n\\`features/<FEAT>/capabilities/<id>/spec.md\\`, the same\n\\`## ADDED|MODIFIED|REMOVED Requirements\\` grammar the service deltas use, the\nsame nesting (\\`features/<FEAT>/capabilities/payments/refunds/\\`), the same\n\\`Based-On:\\` pins, and the same \\`delta.*\\` refusals with the capability id as\nthe subject. \\`scaffold.placeholder\\` reads it too, so an unedited template\nheading refuses the archive here as it does in a spec delta, and\n\\`capability.doc-missing\\` (warn) names a directory in it that holds no\n\\`spec.md\\` — an empty one is not a delta, so the merge would carry nothing.\n\\`loam archive\\` merges it into the living document in the same\ntransaction as the service merge, creating \\`capabilities/<id>/spec.md\\` — and\nso the whole tree — when this is the first feature to mention it. Only what\nthe delta marks as the document's own comes across: its H1 as the title\n(unless it names the feature or calls itself a delta — then the title is the\nid), its \\`## Purpose\\` section as the narrative, and a line linking back to the\narchived delta for everything else, because loam merges requirements and never\nprose; after that the narrative is yours to edit in place. The document's three rules above are\ngraded on the delta BEFORE the merge, so a capability requirement filed at the\nwrong altitude is refused while you still hold it. Editing the living document\ndirectly is still legal; the delta is what makes two features touching one\npromise collide loudly instead of silently. \\`loam new <FEAT> --capability <id>\\`\nscaffolds that delta, and \\`loam show <FEAT>\\` and \\`loam delta <FEAT>\\` list the\npromises a feature changes — a capability delta names no service, so without\nthose two a business-only feature reads as a feature carrying nothing.\n\nA service requirement says which promise it serves with \\`Realizes:\\`, entries\nspelled \\`<capability-id>#<Requirement-ID>\\`. This is the join the tree exists\nfor, and it is NOT the same claim as \\`Capability:\\` beside it — that names a\ntheme, this names one promise, and a requirement commonly carries both. The\ncapability half of an entry is what makes the target addressable, since a\n\\`Requirement-ID\\` is unique only inside its own document; the separator is the\nLAST \\`#\\`, because the requirement half's grammar excludes one and the\ncapability half's does not. Written by whoever implements the requirement,\nnever by the analyst — a business document must not be edited every time the\nfleet rearranges which service carries which part.\n\nBoth directions are graded. An entry naming no capability requirement is\n\\`capability.realizes-unknown\\` (error; in a feature delta it gates\n\\`loam archive\\`, \\`--approve\\`-overridable), and its message says which of the\nfive failures happened — malformed entry, undeclared capability, declared but\nundocumented, document with no requirements, or an id that document does not\ndeclare. A capability requirement nothing keeps is\n\\`capability.requirement-unrealized\\` (warn, one per requirement): it never\ngates, because writing the business document ahead of the fleet is the intended\nuse. \\`loam list capabilities --json\\` carries the whole join — each capability's\nrequirements, and what realizes each one.\n\n\\`Realizes:\\` is not the only way to keep a promise, and for a criterion that\nCROSSES services it is not enough: \"I enter a login and a password and I am in\"\nbelongs to no single service's spec, because each promises only its own part. A\nUSE CASE can carry it, because it IS the hop sequence. So a \\`dynamic view\\`\nalready tagged \\`#cap-<slug>\\` may carry \\`#req-<slug>\\` as well, naming one of\nthat capability's requirements — the architect's answer to the analyst's\npromise, graded by the same four \\`usecase.*\\` codes down to the operation. The\nsecond tag is SCOPED by the first: a \\`Requirement-ID\\` is unique only inside its\nown document, so a \\`#req-\\` tag on a view that resolves no capability, or two, is\n\\`usecase.requirement-unresolved\\` (error) rather than a guess. Several \\`#req-\\`\ntags on one view are legal — a flow commonly keeps two promises. Both tags spell\ntheir id with every character outside \\`[A-Za-z0-9_-]\\` flattened to \\`-\\`,\nbecause that is all a LikeC4 tag name accepts.\n\nAgainst that vocabulary an undeclared name is \\`capability.unknown\\` (error; in\na feature delta it gates \\`loam archive\\`, \\`--approve\\`-overridable), an\nunreadable \\`capabilities.yaml\\` is \\`capability.invalid\\` exactly once per run\nwith every grade that resolves against the vocabulary suspended behind it, and\na declared capability no living requirement realizes is\n\\`capability.unrealized\\` (warn, one per capability). The fleet total is\nreadable: \\`loam list capabilities\\` reports each capability's realizing\nrequirements, their services and the draft/verified split, and\n\\`loam explore --capability <id>\\` seeds an exploration from the realizing\nservices.\n\n## The requirement baseline — \\`Based-On:\\`\n\nA MODIFIED requirement carries its FULL new text, not a diff, so archive does not\nmerge your wording into the living one — it REPLACES it. When two features rewrite\nthe same requirement, the loser loses everything they wrote, scenarios and all.\n\n\\`loam validate\\` names the other feature while both are in flight\n(\\`delta.modified-conflict\\`), but that warning cannot see the case that actually\nhappens: the first feature archives, stops being an active feature, the second\nrevalidates GREEN, and its archive lands text written against a document that no\nlonger exists — \\`+0 ~1 -0\\`, exit 0, nobody told.\n\nSo a MODIFIED or REMOVED requirement pins the living version it was written\nagainst, directly under its identity:\n\n\\`\\`\\`markdown\n### Requirement: Cancel an order\nRequirement-ID: REQ-042\nBased-On: 3bcc7a40f2b23ff3\n\\`\\`\\`\n\nYou do not compute that value — \\`loam rebase FEAT-101\\` writes it, for every\nMODIFIED/REMOVED requirement in the feature, from the living text as it stands\nright now. Run it when you finish authoring a delta, and again after you resolve\na collision. Archive refuses on a stale pin (\\`delta.baseline-stale\\`) and says\nboth digests.\n\n**Restamping is not resolving.** A pin claims \"I read this version\". If\n\\`loam rebase\\` reports a requirement as moved, re-read the living requirement and\nfold in what you still mean BEFORE you ship — otherwise you have re-pinned to a\ndocument you never read, and archive will merge your text over theirs with\nloam's blessing. There is no automatic three-way merge and there will not be one:\nrequirement prose does not merge, people do.\n\nA delta adopted from OpenSpec has no such line and gets a warning\n(\\`delta.baseline-missing\\`) — one that GATES the archive: unpinned is exactly\nthe shape that reverts someone else's landed change at exit 0. A migrated\ncorpus is not stranded by this: \\`loam rebase <FEAT>\\` pins every delta in one\ncommand, and a human's \\`--approve\\` archives unpinned when the loss is meant.\n\n### The same pin on the contract axis\n\nA feature's \\`openapi.yaml\\` is a self-contained document holding ONLY what the\nfeature adds, changes or removes — not a copy of the living contract. The merge\nwalks only the paths and methods the delta spells: an operation you leave out\nstays exactly as the living contract has it, a local \\`$ref\\`\n(\\`#/components/schemas/Order\\`) resolves into the living document, and a new\noperation has no living version to pin — an add-only delta needs no rebase.\n\nWhat the merge does upsert is every operation the document DOES spell. So an\noperation you quote without changing it — copied for context, or a whole\ncontract pasted in — is a collision waiting for someone else's edit: two\nfeatures over one service, each quoting the operation the other edits, destroy\neach other, and the second to archive pushes its authoring-time copy back over\nwhatever landed in between. Quote nothing you do not change. Each quote costs a\npin, and a parallel feature that REMOVES the quoted operation makes it worse\neither way: pinned, the quote is \\`openapi.baseline-invalid\\`, an error that\nblocks your archive, and \\`openapi.op-revived\\` beside it; unpinned, it is\n\\`openapi.op-revived\\` alone — a warning that gates, because the merge would\nread the dead operation as a new one and put it back (\\`asyncapi.slot-revived\\`\nis the same finding on a channel, operation or message slot). A parallel\nfeature that MOVES the operation to another address does the same to a quote\nof the old one, which archived would answer the operationId at both. The fix\nfor both is to delete the quote. Keep it only when the feature brings a\nretired operation back ON PURPOSE: then drop any pin, and a human archives\nwith \\`--approve\\`. \\`loam rebase\\` never pins a retired operation as new —\nnothing lives at its slot, so there is no version to pin — and prints the same\nfinding (\\`revived[]\\` in \\`--json\\`), so the decision stays with you. It judges\nthe delta as it will write it, pins included: a quote of an address another\noperation lives at now — one a move vacated, since re-occupied — IS repinned,\nover the operation living there, which makes it an edit the merge would write;\nthe revival that edit makes is reported by that rebase (or its \\`--dry-run\\`),\nnot first by the next validate. The check reads the removal\nmarkers of the features under \\`features/archive/\\` — a removal made by\nhand-editing a living contract is invisible to it.\n\nThe guard against that collision, for every living operation the delta does\nspell, is a pin — a vendor extension beside \\`x-loam-remove\\`:\n\n\\`\\`\\`yaml\npaths:\n  /orders/{id}/cancel:\n    post:\n      operationId: cancelOrder\n      x-loam-based-on: 86feabe621ed887d\n\\`\\`\\`\n\n\\`loam rebase\\` writes one on every operation in the delta the living contract\nalready holds, pinned to the living version; what the feature adds gets none.\nThat is what lets the merge tell a QUOTE from an EDIT:\n\n- pin equals the operation's own content → you quoted it → **the merge skips it\n  entirely** and the living contract keeps whatever it holds. Archive prints\n  \\`· quotes …\\` so the plan never silently writes less than your delta spells.\n- pin equals the living operation → you edited it, nobody else did → merged.\n- pin matches neither → you edited it AND somebody landed a change to it →\n  \\`openapi.baseline-stale\\`, refused.\n\nThe two surfaces an in-operation key cannot reach — path-level keys\n(\\`parameters\\`, \\`servers\\`, \\`summary\\`, \\`x-*\\`) and every\n\\`components/<kind>/<name>\\` — are pinned the same way through one root record,\n\\`x-loam-baselines\\`, which \\`loam rebase\\` also writes and the merge strips: a\nquoted key or component is skipped, an edited one is written and warned as\n\\`openapi.path-item-modified\\` / \\`openapi.component-modified\\`. A new component\nis copied in when something the merge writes references it; a living one you\nonly \\`$ref\\` needs no copy in the delta at all. Removal markers carry no pin;\n\\`openapi.remove-target-mismatch\\` is what guards those.\n\n## Drawing a shared broker\n\nA broker drawn as ONE element is the node every service in the fleet points at,\nand any view over it is a star nobody can read. Nothing in loam catches this —\nloam parses the model and renders no view, so the map can be perfectly valid and\ncompletely illegible. Two habits keep it readable, and both are cheap only\nbefore the fleet is drawn:\n\n**Model the topic, not the broker.** Nest a topic per channel inside the broker's\nelement and point the edges at it — \\`paymentService -> kafka.paymentEvents\\`, not\n\\`paymentService -> kafka\\`. One hub of degree sixty becomes twelve of degree\nfive, and it is the truer model besides: what a producer and a consumer share is\nthe topic, never the broker. Every check joins the same way, because an edge into\na nested element resolves to the element that owns it. Declare the kind once —\n\n    specification {\n      element topic {\n        style { shape queue }\n      }\n    }\n\nThe KIND is what does the work: since 2026-09-07 loam reads \\`database\\`, \\`queue\\`,\n\\`topic\\`, \\`cache\\` and \\`bucket\\` as infrastructure rather than as candidate\nservices, so a topic drawn this way is out of the service census and nobody is\nasked for a \\`services/payment.events/\\` (measured: the same element spelled\n\\`container\\` earns \\`landscape.service-undocumented\\`, spelled \\`topic\\` it earns\nnothing). This used to need \\`#external\\` ON THE KIND as a workaround, because\n**LikeC4 does not inherit tags** and a topic nested inside an \\`#external\\` broker\nis not external itself. That workaround is no longer owed. Tag the kind\n\\`#external\\` if you want the topics out of the fleet VIEW as well — that is what\nthe next paragraph's \\`exclude\\` reads, and it is a rendering choice now rather\nthan a way to silence a check.\n\n**Scope the views.** \\`exclude element.tag = #external\\` keeps the fleet overview to\nthe calls between our own services; a second view over the broker draws the event\nspine on its own. Views are LikeC4's and loam computes none, so this costs loam\nnothing and is worth doing anyway — an \\`include *\\` over the whole fleet map is\nalso the one view whose computation takes minutes rather than milliseconds. The\nscaffolded landscape applies the same pruning to ubiquitous infrastructure with\n\\`#platform\\`: the fleet view excludes it, and the platform view's\n\\`include * -> element.tag = #platform\\` (the relationship form — the obvious\nspelling draws boxes with no edges) keeps \"who depends on it\" answerable.\n\n## A message produced outside the fleet\n\nA platform service that is not ours — a config service, an auth broker —\nproduces messages our services consume, and no \\`services/<id>/\\` will ever hold\nits contract. Declare the production on the landscape, where the element\nalready says \\`#external\\`:\n\n    externalConfig = softwareSystem 'external-config' {\n      #external\n    }\n    externalConfig -> kafka.configTopic 'publishes config refreshes' {\n      metadata { publishes 'config.ConfigRefreshed' }\n    }\n\n\\`spine.message-unproduced\\` then stops firing — the message HAS a producer,\noutside the fleet — and the contract question moves to the one file that can\nanswer it: the consuming service's own asyncapi.yaml. While that file declares\nno shape for the message, \\`spine.message-external\\` (warn) says so; once the\nconsumer declares the payload, the axis is quiet. A truthful map and a green\nbuild no longer exclude each other, which is the exact choice this used to force.\n`,\n};\n"]}

package/dist/core/asyncapi/baseline/plan.js

@@ -0,0 +1,43 @@
+/**
+ * What `loam rebase` writes on the event axis's SURFACE half: the
+ * `x-loam-baselines` record, rebuilt wholesale from what is on disk right now
+ * — `core/openapi/baseline/plan.ts`'s planner itself, over component surfaces
+ * instead of path items and components.
+ *
+ * A ROOT record rather than an in-value pin, and that is not symmetry for its
+ * own sake: a slot value is always a mapping, so `x-loam-based-on` has
+ * somewhere to live inside it, but a `components/schemas/<name>` value is a
+ * JSON Schema — where an in-value loam key would be a schema keyword, and
+ * where JSON Schema's own `true` is a legal component that no in-value key
+ * survives at all.
+ *
+ * Rebuilt rather than patched for the reason the OpenAPI plan states: a pin is
+ * a claim about what its author read, and an entry left behind for a surface
+ * the delta no longer declares — or one whose living counterpart is gone — is
+ * a claim nobody is making any more. The sorted serialization (`buildRecord`)
+ * is what makes a second run byte-identical.
+ *
+ * The planner is SHARED, not mirrored: it used to be a line-for-line copy of
+ * the OpenAPI one minus the path-item arm, and the only real difference was
+ * which walk enumerates the surfaces. `asyncapiSurfaces` is that walk, so this
+ * module passes it and owns nothing else.
+ *
+ * This module must not import from `../merge/`: the merge reads this package,
+ * so a value edge back would be a package cycle. That is also why an
+ * unreadable document is answered with "nothing to pin" rather than an
+ * `AsyncapiMergeError` — every caller chains this AFTER `pinAsyncapiSlots`,
+ * which has already thrown that error for a document either side cannot parse.
+ */
+import { planOpenapiBaselines } from "../../openapi/baseline/plan.js";
+import { asyncapiSurfaces } from "./surfaces.js";
+/**
+ * Pin every component surface of a feature event contract against the living
+ * one — every `kind` in the answer is `"component"`, since an event contract
+ * has no path items. The rules (the LIVING digest, `unresolved` for a surface
+ * the living contract lacks, the idempotent rewrite) are the shared planner's,
+ * stated there once.
+ */
+export function planAsyncapiBaselines(featureText, livingText) {
+    return planOpenapiBaselines(featureText, livingText, asyncapiSurfaces);
+}
+//# sourceMappingURL=plan.js.map

package/dist/core/asyncapi/baseline/plan.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"plan.js","sourceRoot":"","sources":["../../../../src/core/asyncapi/baseline/plan.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,OAAO,EAAE,oBAAoB,EAA4B,MAAM,gCAAgC,CAAC;AAChG,OAAO,EAAE,gBAAgB,EAAE,MAAM,eAAe,CAAC;AAEjD;;;;;;GAMG;AACH,MAAM,UAAU,qBAAqB,CAAC,WAAmB,EAAE,UAAkB;IAC3E,OAAO,oBAAoB,CAAC,WAAW,EAAE,UAAU,EAAE,gBAAgB,CAAC,CAAC;AACzE,CAAC","sourcesContent":["/**\n * What `loam rebase` writes on the event axis's SURFACE half: the\n * `x-loam-baselines` record, rebuilt wholesale from what is on disk right now\n * — `core/openapi/baseline/plan.ts`'s planner itself, over component surfaces\n * instead of path items and components.\n *\n * A ROOT record rather than an in-value pin, and that is not symmetry for its\n * own sake: a slot value is always a mapping, so `x-loam-based-on` has\n * somewhere to live inside it, but a `components/schemas/<name>` value is a\n * JSON Schema — where an in-value loam key would be a schema keyword, and\n * where JSON Schema's own `true` is a legal component that no in-value key\n * survives at all.\n *\n * Rebuilt rather than patched for the reason the OpenAPI plan states: a pin is\n * a claim about what its author read, and an entry left behind for a surface\n * the delta no longer declares — or one whose living counterpart is gone — is\n * a claim nobody is making any more. The sorted serialization (`buildRecord`)\n * is what makes a second run byte-identical.\n *\n * The planner is SHARED, not mirrored: it used to be a line-for-line copy of\n * the OpenAPI one minus the path-item arm, and the only real difference was\n * which walk enumerates the surfaces. `asyncapiSurfaces` is that walk, so this\n * module passes it and owns nothing else.\n *\n * This module must not import from `../merge/`: the merge reads this package,\n * so a value edge back would be a package cycle. That is also why an\n * unreadable document is answered with \"nothing to pin\" rather than an\n * `AsyncapiMergeError` — every caller chains this AFTER `pinAsyncapiSlots`,\n * which has already thrown that error for a document either side cannot parse.\n */\nimport { planOpenapiBaselines, type OpenapiBaselinePlan } from \"../../openapi/baseline/plan.js\";\nimport { asyncapiSurfaces } from \"./surfaces.js\";\n\n/**\n * Pin every component surface of a feature event contract against the living\n * one — every `kind` in the answer is `\"component\"`, since an event contract\n * has no path items. The rules (the LIVING digest, `unresolved` for a surface\n * the living contract lacks, the idempotent rewrite) are the shared planner's,\n * stated there once.\n */\nexport function planAsyncapiBaselines(featureText: string, livingText: string): OpenapiBaselinePlan {\n  return planOpenapiBaselines(featureText, livingText, asyncapiSurfaces);\n}\n"]}

package/dist/core/asyncapi/baseline/surfaces.js

@@ -0,0 +1,54 @@
+/**
+ * The values a feature event contract restates that the SLOT pin cannot reach:
+ * every `components/<kind>/<name>` outside `messages`.
+ *
+ * A package of its own rather than a sixth file in `core/asyncapi/` — that
+ * directory is exactly at the five-file limit — and a separate ENUMERATION
+ * from the OpenAPI axis's `restatedSurfaces` rather than an import of it,
+ * although the two are the same shape. `restatedSurfaces` walks `paths` (a key
+ * an AsyncAPI document does not have) and includes `components/messages`,
+ * which on this axis is a SLOT: a message pinned both in-value by
+ * `x-loam-based-on` and by a root record entry would have two identities, and
+ * the merge would classify it twice — once as a slot, once as a surface — with
+ * verdicts that need not agree. What IS shared is everything downstream of the
+ * enumeration: `readBaselineRecord`, `entryFor`, `surfaceIn` and the record's
+ * `components` half are axis-neutral, so the record means the same thing on
+ * both axes and only the walk that fills it differs.
+ *
+ * Import direction is asyncapi → openapi, as core/asyncapi/digest.ts's header
+ * states; nothing under core/openapi/ imports this package.
+ */
+import { isRecord } from "../../kernel/records.js";
+import { FEATURE_ONLY_KEYS } from "../../openapi/digest.js";
+/**
+ * Every component surface a plain-parsed feature document declares, in
+ * document order.
+ *
+ * `messages` is skipped because it is the third slot section (core/asyncapi/
+ * digest.ts): a message carries its own in-value pin, and giving it a root
+ * record entry as well would be two pins on one value. The feature-only keys
+ * are skipped in the KIND position because `components: {x-loam-remove: true,
+ * schemas: {…}}` is bookkeeping sitting where a component kind goes — the
+ * strip already treats it that way, and a surface named after a marker would
+ * be pinned by `loam rebase` and then graded as an orphan the moment the strip
+ * took it out.
+ */
+export function asyncapiSurfaces(plain) {
+    const out = [];
+    if (!isRecord(plain))
+        return out;
+    const comps = plain["components"];
+    if (!isRecord(comps))
+        return out;
+    for (const [kind, names] of Object.entries(comps)) {
+        if (kind === "messages" || FEATURE_ONLY_KEYS.has(kind))
+            continue;
+        if (!isRecord(names))
+            continue;
+        for (const [name, value] of Object.entries(names)) {
+            out.push({ kind: "component", id: `${kind}/${name}`, value });
+        }
+    }
+    return out;
+}
+//# sourceMappingURL=surfaces.js.map

package/dist/core/asyncapi/baseline/surfaces.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"surfaces.js","sourceRoot":"","sources":["../../../../src/core/asyncapi/baseline/surfaces.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;GAmBG;AACH,OAAO,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AACnD,OAAO,EAAE,iBAAiB,EAAE,MAAM,yBAAyB,CAAC;AAW5D;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,gBAAgB,CAAC,KAAc;IAC7C,MAAM,GAAG,GAAsB,EAAE,CAAC;IAClC,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC;QAAE,OAAO,GAAG,CAAC;IACjC,MAAM,KAAK,GAAG,KAAK,CAAC,YAAY,CAAC,CAAC;IAClC,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC;QAAE,OAAO,GAAG,CAAC;IACjC,KAAK,MAAM,CAAC,IAAI,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,EAAE,CAAC;QAClD,IAAI,IAAI,KAAK,UAAU,IAAI,iBAAiB,CAAC,GAAG,CAAC,IAAI,CAAC;YAAE,SAAS;QACjE,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC;YAAE,SAAS;QAC/B,KAAK,MAAM,CAAC,IAAI,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,EAAE,CAAC;YAClD,GAAG,CAAC,IAAI,CAAC,EAAE,IAAI,EAAE,WAAW,EAAE,EAAE,EAAE,GAAG,IAAI,IAAI,IAAI,EAAE,EAAE,KAAK,EAAE,CAAC,CAAC;QAChE,CAAC;IACH,CAAC;IACD,OAAO,GAAG,CAAC;AACb,CAAC","sourcesContent":["/**\n * The values a feature event contract restates that the SLOT pin cannot reach:\n * every `components/<kind>/<name>` outside `messages`.\n *\n * A package of its own rather than a sixth file in `core/asyncapi/` — that\n * directory is exactly at the five-file limit — and a separate ENUMERATION\n * from the OpenAPI axis's `restatedSurfaces` rather than an import of it,\n * although the two are the same shape. `restatedSurfaces` walks `paths` (a key\n * an AsyncAPI document does not have) and includes `components/messages`,\n * which on this axis is a SLOT: a message pinned both in-value by\n * `x-loam-based-on` and by a root record entry would have two identities, and\n * the merge would classify it twice — once as a slot, once as a surface — with\n * verdicts that need not agree. What IS shared is everything downstream of the\n * enumeration: `readBaselineRecord`, `entryFor`, `surfaceIn` and the record's\n * `components` half are axis-neutral, so the record means the same thing on\n * both axes and only the walk that fills it differs.\n *\n * Import direction is asyncapi → openapi, as core/asyncapi/digest.ts's header\n * states; nothing under core/openapi/ imports this package.\n */\nimport { isRecord } from \"../../kernel/records.js\";\nimport { FEATURE_ONLY_KEYS } from \"../../openapi/digest.js\";\nimport type { RestatedSurface } from \"../../openapi/baseline/record.js\";\n\n/**\n * One surface of an event contract. Structurally the OpenAPI record's\n * component branch, on purpose: `entryFor` and `surfaceIn` take that union, so\n * a separate shape here would mean a second spelling of \"the record's entry\n * for this value\" — the drift both axes' digest modules exist to prevent.\n */\nexport type AsyncapiSurface = Extract<RestatedSurface, { kind: \"component\" }>;\n\n/**\n * Every component surface a plain-parsed feature document declares, in\n * document order.\n *\n * `messages` is skipped because it is the third slot section (core/asyncapi/\n * digest.ts): a message carries its own in-value pin, and giving it a root\n * record entry as well would be two pins on one value. The feature-only keys\n * are skipped in the KIND position because `components: {x-loam-remove: true,\n * schemas: {…}}` is bookkeeping sitting where a component kind goes — the\n * strip already treats it that way, and a surface named after a marker would\n * be pinned by `loam rebase` and then graded as an orphan the moment the strip\n * took it out.\n */\nexport function asyncapiSurfaces(plain: unknown): AsyncapiSurface[] {\n  const out: AsyncapiSurface[] = [];\n  if (!isRecord(plain)) return out;\n  const comps = plain[\"components\"];\n  if (!isRecord(comps)) return out;\n  for (const [kind, names] of Object.entries(comps)) {\n    if (kind === \"messages\" || FEATURE_ONLY_KEYS.has(kind)) continue;\n    if (!isRecord(names)) continue;\n    for (const [name, value] of Object.entries(names)) {\n      out.push({ kind: \"component\", id: `${kind}/${name}`, value });\n    }\n  }\n  return out;\n}\n"]}