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

package/dist/core/agent/agents-md/map/lenses/context.js

@@ -0,0 +1,41 @@
+/**
+ * The `loam context` entry of the command map — one of the three consumer
+ * LENSES this package holds (the agent briefing here, `./gate.ts`'s deploy
+ * pipeline, `./diff.ts`'s PR review), the family carved out of `../` when the
+ * map package hit its own five-file cap: command-map.ts sits against the
+ * file-line limit, so the pack's documentation lives down here and is
+ * concatenated after the map.
+ *
+ * Same assembly contract as every section: ../../../agents-md.ts concatenates
+ * with NO join separator, so this string starts at the first character of its
+ * opening line and ends with the newline that closes its last one.
+ */
+export const CONTEXT_COMMAND = `- \`loam context <service>\` assembles the docs slice bound to one service as a
+  single deterministic briefing — the pack an agent loads before working in
+  that service's repository. It writes nothing. One payload carries the living
+  requirements and arch requirements VERBATIM (bodies and scenarios included),
+  the OpenAPI operations with the requirements governing each, the AsyncAPI
+  messages with their send/receive direction, the fleet edges one hop out with
+  the map's own health beside them (\`landscape.present\`/\`parses\` — an empty
+  edge list under a map that does not parse is "nobody could look", never
+  "nobody calls this"), the \`Requires:\` permissions resolved against the
+  vocabulary (an undeclared entry is carried with \`declared: false\`, never
+  refused — and when the vocabulary ITSELF does not read, its parse failure
+  rides beside them, so \`declared: false\` there means nobody could look, not
+  that the claim is wrong), the capabilities this service realizes with the
+  capability vocabulary's own health beside them, maturity and provenance,
+  presence pointers for the runbook/health/ADRs, and every ACTIVE feature's
+  delta over this service in \`loam delta\`'s own shapes. \`--feature <FEAT>\`
+  narrows the in-flight section to that one feature and is echoed back as the
+  \`feature\` key, so a narrowed pack says it is one; a known feature that does
+  not touch the service still projects, with empty sections and its own
+  services list. Exit 1 with \`ok: true\` means a document behind the pack did
+  not parse — the fleet map, a living contract, a fleet vocabulary, another
+  service's spec during the capability join, or an included feature's document
+  (a feature whose delta.likec4 does not parse is still INCLUDED, its errors
+  in the payload, because a change nobody can read is in flight, not absent)
+  — and the empty section beside the flag IS the parse failure, not "nothing
+  here". Identical state yields identical bytes, so packs are diffable across
+  runs.
+`;
+//# sourceMappingURL=context.js.map

package/dist/core/agent/agents-md/map/lenses/context.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"context.js","sourceRoot":"","sources":["../../../../../../src/core/agent/agents-md/map/lenses/context.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AACH,MAAM,CAAC,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2B9B,CAAC","sourcesContent":["/**\n * The `loam context` entry of the command map — one of the three consumer\n * LENSES this package holds (the agent briefing here, `./gate.ts`'s deploy\n * pipeline, `./diff.ts`'s PR review), the family carved out of `../` when the\n * map package hit its own five-file cap: command-map.ts sits against the\n * file-line limit, so the pack's documentation lives down here and is\n * concatenated after the map.\n *\n * Same assembly contract as every section: ../../../agents-md.ts concatenates\n * with NO join separator, so this string starts at the first character of its\n * opening line and ends with the newline that closes its last one.\n */\nexport const CONTEXT_COMMAND = `- \\`loam context <service>\\` assembles the docs slice bound to one service as a\n  single deterministic briefing — the pack an agent loads before working in\n  that service's repository. It writes nothing. One payload carries the living\n  requirements and arch requirements VERBATIM (bodies and scenarios included),\n  the OpenAPI operations with the requirements governing each, the AsyncAPI\n  messages with their send/receive direction, the fleet edges one hop out with\n  the map's own health beside them (\\`landscape.present\\`/\\`parses\\` — an empty\n  edge list under a map that does not parse is \"nobody could look\", never\n  \"nobody calls this\"), the \\`Requires:\\` permissions resolved against the\n  vocabulary (an undeclared entry is carried with \\`declared: false\\`, never\n  refused — and when the vocabulary ITSELF does not read, its parse failure\n  rides beside them, so \\`declared: false\\` there means nobody could look, not\n  that the claim is wrong), the capabilities this service realizes with the\n  capability vocabulary's own health beside them, maturity and provenance,\n  presence pointers for the runbook/health/ADRs, and every ACTIVE feature's\n  delta over this service in \\`loam delta\\`'s own shapes. \\`--feature <FEAT>\\`\n  narrows the in-flight section to that one feature and is echoed back as the\n  \\`feature\\` key, so a narrowed pack says it is one; a known feature that does\n  not touch the service still projects, with empty sections and its own\n  services list. Exit 1 with \\`ok: true\\` means a document behind the pack did\n  not parse — the fleet map, a living contract, a fleet vocabulary, another\n  service's spec during the capability join, or an included feature's document\n  (a feature whose delta.likec4 does not parse is still INCLUDED, its errors\n  in the payload, because a change nobody can read is in flight, not absent)\n  — and the empty section beside the flag IS the parse failure, not \"nothing\n  here\". Identical state yields identical bytes, so packs are diffable across\n  runs.\n`;\n"]}

package/dist/core/agent/agents-md/map/lenses/diff.js

@@ -0,0 +1,46 @@
+/**
+ * The `loam diff` entry of the command map — the PR-review lens of this
+ * package, split out for `./context.ts`'s exact reason: command-map.ts sat
+ * against the file-line limit, so the branch-diff surface's documentation
+ * lives down here and is concatenated after the map. It is also the
+ * documentation home of the whole `diff.*` code vocabulary, which
+ * codes-drift requires.
+ *
+ * The codes are grouped by the ARTIFACT they are computed over and not
+ * glossed: that grouping is what nothing else says, while
+ * `loam explain diff.op-removed-consumed` (and every sibling) carries the
+ * meaning, the severity and the fix. See ../../command-map.ts's header for why
+ * the gloss left.
+ *
+ * Same assembly contract as every section: ../../../agents-md.ts concatenates
+ * with NO join separator, so this string starts at the first character of its
+ * opening line and ends with the newline that closes its last one.
+ */
+export const DIFF_COMMAND = `- \`loam diff --base <ref>\` reports the fleet-meaningful changes between the
+  living docs and a base git ref of the DOCS repo (a branch, \`origin/main\`, a
+  commit sha) — the review lens for a docs-repo PR. Read-only: the base state
+  is read with read-only git questions (\`rev-parse\`/\`ls-tree\`/\`show\`), no
+  checkout, nothing written. \`validate --all\` stays the fleet gate; diff says
+  what a branch CHANGES, and names who currently depends on every removal.
+  Codes, per service and grouped by the artifact they are computed over:
+  \`diff.service-added\` and \`diff.service-removed\` over the \`services/<id>/\`
+  directory; \`diff.requirement-added\`, \`diff.requirement-removed\` and
+  \`diff.requirement-modified\` over spec.md's living requirements;
+  \`diff.op-added\`, \`diff.op-removed\`, \`diff.op-removed-consumed\` and
+  \`diff.op-deprecated\` over the OpenAPI contract; \`diff.message-added\`,
+  \`diff.message-removed\` and \`diff.message-removed-consumed\` over the AsyncAPI
+  contract; and \`diff.consumer-added\` / \`diff.consumer-removed\` over the
+  cross-service joins — another service's requirement naming this service's
+  operation or message. The two \`-consumed\` codes are the errors: they are the
+  removals something in the fleet still names, with the victims in
+  \`details[]\`. Exit 0 = diff computed, nothing breaking, everything readable;
+  exit 1 = a refusal, any error finding (\`breaking: true\` in \`--json\`), or a
+  subject whose artifact could not be read on either side — those axes are
+  SUSPENDED and reported (\`unreadable\` in the payload and the summary), never
+  graded as "nothing changed" or "everything added". Refusals reuse existing
+  codes: \`repository-unavailable\` when the docs repo has no git history to ask,
+  and \`unknown-target\` when \`--base\` resolves to no commit there. For the
+  byte-level OpenAPI breaking-change catalogue, run oasdiff on the two states
+  of one contract instead — loam deliberately does not reimplement it.
+`;
+//# sourceMappingURL=diff.js.map

package/dist/core/agent/agents-md/map/lenses/diff.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"diff.js","sourceRoot":"","sources":["../../../../../../src/core/agent/agents-md/map/lenses/diff.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AACH,MAAM,CAAC,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;CA0B3B,CAAC","sourcesContent":["/**\n * The `loam diff` entry of the command map — the PR-review lens of this\n * package, split out for `./context.ts`'s exact reason: command-map.ts sat\n * against the file-line limit, so the branch-diff surface's documentation\n * lives down here and is concatenated after the map. It is also the\n * documentation home of the whole `diff.*` code vocabulary, which\n * codes-drift requires.\n *\n * The codes are grouped by the ARTIFACT they are computed over and not\n * glossed: that grouping is what nothing else says, while\n * `loam explain diff.op-removed-consumed` (and every sibling) carries the\n * meaning, the severity and the fix. See ../../command-map.ts's header for why\n * the gloss left.\n *\n * Same assembly contract as every section: ../../../agents-md.ts concatenates\n * with NO join separator, so this string starts at the first character of its\n * opening line and ends with the newline that closes its last one.\n */\nexport const DIFF_COMMAND = `- \\`loam diff --base <ref>\\` reports the fleet-meaningful changes between the\n  living docs and a base git ref of the DOCS repo (a branch, \\`origin/main\\`, a\n  commit sha) — the review lens for a docs-repo PR. Read-only: the base state\n  is read with read-only git questions (\\`rev-parse\\`/\\`ls-tree\\`/\\`show\\`), no\n  checkout, nothing written. \\`validate --all\\` stays the fleet gate; diff says\n  what a branch CHANGES, and names who currently depends on every removal.\n  Codes, per service and grouped by the artifact they are computed over:\n  \\`diff.service-added\\` and \\`diff.service-removed\\` over the \\`services/<id>/\\`\n  directory; \\`diff.requirement-added\\`, \\`diff.requirement-removed\\` and\n  \\`diff.requirement-modified\\` over spec.md's living requirements;\n  \\`diff.op-added\\`, \\`diff.op-removed\\`, \\`diff.op-removed-consumed\\` and\n  \\`diff.op-deprecated\\` over the OpenAPI contract; \\`diff.message-added\\`,\n  \\`diff.message-removed\\` and \\`diff.message-removed-consumed\\` over the AsyncAPI\n  contract; and \\`diff.consumer-added\\` / \\`diff.consumer-removed\\` over the\n  cross-service joins — another service's requirement naming this service's\n  operation or message. The two \\`-consumed\\` codes are the errors: they are the\n  removals something in the fleet still names, with the victims in\n  \\`details[]\\`. Exit 0 = diff computed, nothing breaking, everything readable;\n  exit 1 = a refusal, any error finding (\\`breaking: true\\` in \\`--json\\`), or a\n  subject whose artifact could not be read on either side — those axes are\n  SUSPENDED and reported (\\`unreadable\\` in the payload and the summary), never\n  graded as \"nothing changed\" or \"everything added\". Refusals reuse existing\n  codes: \\`repository-unavailable\\` when the docs repo has no git history to ask,\n  and \\`unknown-target\\` when \\`--base\\` resolves to no commit there. For the\n  byte-level OpenAPI breaking-change catalogue, run oasdiff on the two states\n  of one contract instead — loam deliberately does not reimplement it.\n`;\n"]}

package/dist/core/agent/agents-md/map/lenses/gate.js

@@ -0,0 +1,57 @@
+/**
+ * The `loam gate` entry of the command map — the deploy-pipeline lens of this
+ * package, split out for `./context.ts`'s exact reason: command-map.ts sat
+ * against the file-line limit, so the deploy gate's documentation lives down
+ * here and is concatenated after the map. Its four `gate.*` codes are what
+ * test/codes-drift.test.ts finds here.
+ *
+ * The codes are grouped by CHECK and not glossed: which check raises what is
+ * the payload's own `checks[]` shape and is the unique thing this section
+ * says, while `loam explain gate.partners-unknown` (and every sibling) carries
+ * the meaning, the conditional severity and the fix. See ../../command-map.ts's
+ * header for why the gloss left.
+ *
+ * Same assembly contract as every section: ../../../agents-md.ts concatenates
+ * with NO join separator, so this string starts at the first character of its
+ * opening line and ends with the newline that closes its last one.
+ */
+export const GATE_COMMAND = `- \`loam gate [--service <id>]\` is the DEPLOY-pipeline question — can this
+  service deploy, as far as recorded evidence can say — asked as a pure query:
+  it executes nothing, writes nothing, takes no lock, and deliberately changes
+  nothing about what gates \`loam archive\` (verify still never gates the
+  merge; gate's verdict is advice to a pipeline loam does not own). In a bound
+  service repo the invocation is literally \`loam gate --json\`; \`--service\`
+  names any other adopted service, and one nobody adopted refuses
+  \`unknown-service\` — recorded evidence cannot answer for it. Four checks, and
+  the code tells you which one spoke. \`partners\` derives the direct joins from
+  the LIVING landscape: \`gate.service-undocumented\`,
+  \`gate.partner-undocumented\` and \`gate.partners-unknown\` — the last one
+  severity-splits on why the map could not answer, so read
+  \`loam explain gate.partners-unknown\` before treating it as advisory. A
+  partner tagged \`#external\` is exempt from the middle one on purpose — its
+  docs are somebody else's — but an ADOPTED service is never exempt, whatever
+  zone the map draws it inside.
+  \`freshness\` re-reports two staleness findings \`validate\` already owns,
+  \`content.stale\` and \`sources.stale\`, over the gated service and its
+  documented partners, plus the one integrity error that makes freshness
+  unjudgeable, \`frontmatter.malformed\`; it decodes the spec bytes itself, so a
+  UTF-16 spec.md is a \`service.unreadable\` error naming the file, never a quiet
+  pass. The rest of provenance stays \`validate\`'s report to make.
+  \`verification\` covers every ACTIVE feature carrying a specs/ delta for the
+  service, through the verification record's own verdicts:
+  \`gate.feature-unverified\` and the reused \`verify.scenario-attested\`.
+  \`interrupted\` reuses \`docs.commit-interrupted\`: a \`.loam-commit\` journal
+  means the docs may be half-written, so nothing graded from them describes one
+  state. One unreadable sibling artifact degrades that ONE subject as
+  \`service.unreadable\` / \`feature.unreadable\` instead of killing the report.
+  Exit semantics are validate's: any error fails (exit 1, \`verdict: "fail"\`),
+  warnings are advisory (exit 0, \`verdict: "pass"\`), and \`--strict\` is the CI
+  lever that fails warnings too — the report and the \`--json\` payload do not
+  change under it. The payload carries \`landscape\`
+  (\`read\`/\`absent\`/\`invalid\`), \`partners[]\` (each with its maturity
+  rung, role and joins), \`features[]\` (the per-record tallies) and
+  \`checks[]\` (the findings, by check), so a pipeline that wants a stricter
+  bar — \`vouched\` partners, no attested scenarios — branches on the data
+  rather than waiting for a flag.
+`;
+//# sourceMappingURL=gate.js.map

package/dist/core/agent/agents-md/map/lenses/gate.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"gate.js","sourceRoot":"","sources":["../../../../../../src/core/agent/agents-md/map/lenses/gate.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,CAAC,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsC3B,CAAC","sourcesContent":["/**\n * The `loam gate` entry of the command map — the deploy-pipeline lens of this\n * package, split out for `./context.ts`'s exact reason: command-map.ts sat\n * against the file-line limit, so the deploy gate's documentation lives down\n * here and is concatenated after the map. Its four `gate.*` codes are what\n * test/codes-drift.test.ts finds here.\n *\n * The codes are grouped by CHECK and not glossed: which check raises what is\n * the payload's own `checks[]` shape and is the unique thing this section\n * says, while `loam explain gate.partners-unknown` (and every sibling) carries\n * the meaning, the conditional severity and the fix. See ../../command-map.ts's\n * header for why the gloss left.\n *\n * Same assembly contract as every section: ../../../agents-md.ts concatenates\n * with NO join separator, so this string starts at the first character of its\n * opening line and ends with the newline that closes its last one.\n */\nexport const GATE_COMMAND = `- \\`loam gate [--service <id>]\\` is the DEPLOY-pipeline question — can this\n  service deploy, as far as recorded evidence can say — asked as a pure query:\n  it executes nothing, writes nothing, takes no lock, and deliberately changes\n  nothing about what gates \\`loam archive\\` (verify still never gates the\n  merge; gate's verdict is advice to a pipeline loam does not own). In a bound\n  service repo the invocation is literally \\`loam gate --json\\`; \\`--service\\`\n  names any other adopted service, and one nobody adopted refuses\n  \\`unknown-service\\` — recorded evidence cannot answer for it. Four checks, and\n  the code tells you which one spoke. \\`partners\\` derives the direct joins from\n  the LIVING landscape: \\`gate.service-undocumented\\`,\n  \\`gate.partner-undocumented\\` and \\`gate.partners-unknown\\` — the last one\n  severity-splits on why the map could not answer, so read\n  \\`loam explain gate.partners-unknown\\` before treating it as advisory. A\n  partner tagged \\`#external\\` is exempt from the middle one on purpose — its\n  docs are somebody else's — but an ADOPTED service is never exempt, whatever\n  zone the map draws it inside.\n  \\`freshness\\` re-reports two staleness findings \\`validate\\` already owns,\n  \\`content.stale\\` and \\`sources.stale\\`, over the gated service and its\n  documented partners, plus the one integrity error that makes freshness\n  unjudgeable, \\`frontmatter.malformed\\`; it decodes the spec bytes itself, so a\n  UTF-16 spec.md is a \\`service.unreadable\\` error naming the file, never a quiet\n  pass. The rest of provenance stays \\`validate\\`'s report to make.\n  \\`verification\\` covers every ACTIVE feature carrying a specs/ delta for the\n  service, through the verification record's own verdicts:\n  \\`gate.feature-unverified\\` and the reused \\`verify.scenario-attested\\`.\n  \\`interrupted\\` reuses \\`docs.commit-interrupted\\`: a \\`.loam-commit\\` journal\n  means the docs may be half-written, so nothing graded from them describes one\n  state. One unreadable sibling artifact degrades that ONE subject as\n  \\`service.unreadable\\` / \\`feature.unreadable\\` instead of killing the report.\n  Exit semantics are validate's: any error fails (exit 1, \\`verdict: \"fail\"\\`),\n  warnings are advisory (exit 0, \\`verdict: \"pass\"\\`), and \\`--strict\\` is the CI\n  lever that fails warnings too — the report and the \\`--json\\` payload do not\n  change under it. The payload carries \\`landscape\\`\n  (\\`read\\`/\\`absent\\`/\\`invalid\\`), \\`partners[]\\` (each with its maturity\n  rung, role and joins), \\`features[]\\` (the per-record tallies) and\n  \\`checks[]\\` (the findings, by check), so a pipeline that wants a stricter\n  bar — \\`vouched\\` partners, no attested scenarios — branches on the data\n  rather than waiting for a flag.\n`;\n"]}

package/dist/core/agent/agents-md/map/mcp.js

@@ -0,0 +1,41 @@
+/**
+ * The `loam mcp` entry of the command map — its own section module for
+ * `./lenses/gate.ts`'s exact reason: command-map.ts sat against the file-line limit,
+ * so the MCP facade's documentation lives one package down and is
+ * concatenated after the map. It introduces no codes of its own: every tool
+ * result is an existing envelope, which is the point of the section.
+ *
+ * Same assembly contract as every section: ../../agents-md.ts concatenates
+ * with NO join separator, so this string starts at the first character of its
+ * opening line and ends with the newline that closes its last one.
+ *
+ * The command names in the roster below are HAND-LISTED: importing
+ * core/mcp/tools.ts from here would close a package cycle (tools.ts reads
+ * core/explain/terms.ts, which reads this package's siblings for its pin
+ * sources). test/mcp-protocol.test.ts pins this string against MCP_TOOLS
+ * instead: a tool added to the table without its name here fails there.
+ */
+export const MCP_COMMAND = `- \`loam mcp\` serves the fourteen base read commands — validate, status, list, show,
+  delta, diff, explore, dependencies, doctor, context, gate, steps, explain,
+  instructions — as MCP tools over stdio (JSON-RPC 2.0), for hosts that reach
+  tools through MCP rather than a shell:
+  configure the host to launch \`loam mcp\` in the repository the tools should
+  answer for, or run \`loam init --mcp\` there and let it write the \`.mcp.json\`
+  every host reads. Like every other file \`init\` lays down, an existing one is
+  reported and never merged into. Every tool result carries the same \`--json\` envelope the CLI
+  prints, verbatim, so everything above about codes and envelopes applies
+  unchanged — branch on \`ok\` and \`error.code\` exactly as you would reading
+  the command's stdout. The orientation and instruction pages are MCP resources,
+  and every tool declares the envelope output schema. Every base tool is advertised with
+  \`annotations.readOnlyHint: true\` — the machine signal a host needs to
+  approve a call without prompting, and the reason the table stays read-only
+  by construction. The two that read no config, \`explain\` and
+  \`instructions\`, are served so an MCP-only host can reach them BEFORE this
+  repository is wired: the first line of every generated skill is
+  \`loam instructions <workflow>\`, and a host that could not run it could not
+  fetch the protocol its own skill points at. An explicit \`mcp --author\` adds
+  \`new\`, \`rebase\`, \`gherkin\` and an archive dry-run. It never exposes
+  \`vouch\`, evidence recording or a committing archive; those stay in the CLI,
+  where the permission flow is yours.
+`;
+//# sourceMappingURL=mcp.js.map

package/dist/core/agent/agents-md/map/mcp.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"mcp.js","sourceRoot":"","sources":["../../../../../src/core/agent/agents-md/map/mcp.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,CAAC,MAAM,WAAW,GAAG;;;;;;;;;;;;;;;;;;;;;;CAsB1B,CAAC","sourcesContent":["/**\n * The `loam mcp` entry of the command map — its own section module for\n * `./lenses/gate.ts`'s exact reason: command-map.ts sat against the file-line limit,\n * so the MCP facade's documentation lives one package down and is\n * concatenated after the map. It introduces no codes of its own: every tool\n * result is an existing envelope, which is the point of the section.\n *\n * Same assembly contract as every section: ../../agents-md.ts concatenates\n * with NO join separator, so this string starts at the first character of its\n * opening line and ends with the newline that closes its last one.\n *\n * The command names in the roster below are HAND-LISTED: importing\n * core/mcp/tools.ts from here would close a package cycle (tools.ts reads\n * core/explain/terms.ts, which reads this package's siblings for its pin\n * sources). test/mcp-protocol.test.ts pins this string against MCP_TOOLS\n * instead: a tool added to the table without its name here fails there.\n */\nexport const MCP_COMMAND = `- \\`loam mcp\\` serves the fourteen base read commands — validate, status, list, show,\n  delta, diff, explore, dependencies, doctor, context, gate, steps, explain,\n  instructions — as MCP tools over stdio (JSON-RPC 2.0), for hosts that reach\n  tools through MCP rather than a shell:\n  configure the host to launch \\`loam mcp\\` in the repository the tools should\n  answer for, or run \\`loam init --mcp\\` there and let it write the \\`.mcp.json\\`\n  every host reads. Like every other file \\`init\\` lays down, an existing one is\n  reported and never merged into. Every tool result carries the same \\`--json\\` envelope the CLI\n  prints, verbatim, so everything above about codes and envelopes applies\n  unchanged — branch on \\`ok\\` and \\`error.code\\` exactly as you would reading\n  the command's stdout. The orientation and instruction pages are MCP resources,\n  and every tool declares the envelope output schema. Every base tool is advertised with\n  \\`annotations.readOnlyHint: true\\` — the machine signal a host needs to\n  approve a call without prompting, and the reason the table stays read-only\n  by construction. The two that read no config, \\`explain\\` and\n  \\`instructions\\`, are served so an MCP-only host can reach them BEFORE this\n  repository is wired: the first line of every generated skill is\n  \\`loam instructions <workflow>\\`, and a host that could not run it could not\n  fetch the protocol its own skill points at. An explicit \\`mcp --author\\` adds\n  \\`new\\`, \\`rebase\\`, \\`gherkin\\` and an archive dry-run. It never exposes\n  \\`vouch\\`, evidence recording or a committing archive; those stay in the CLI,\n  where the permission flow is yours.\n`;\n"]}

package/dist/core/agent/agents-md/map/status.js

@@ -0,0 +1,62 @@
+/**
+ * The `loam status` entry of the command map — its own section module for
+ * `./mcp.ts`'s exact reason: command-map.ts sat against the file-line limit,
+ * so the orientation surface's documentation lives one package down. Unlike
+ * its siblings it is not concatenated AFTER the map: status is deliberately
+ * the map's FIRST bullet, so ../command-map.ts composes it into COMMAND_MAP
+ * between the preamble and the validate entries. The `next.*` fleet and
+ * feature codes are what test/codes-drift.test.ts finds here.
+ *
+ * The `next.*` codes are LISTED, not glossed: `loam explain next.adopt` (and
+ * every sibling) answers what a step means and what to run, out of the binary
+ * rather than out of this file. See ../command-map.ts's header for why the
+ * gloss left. What survives here is what `explain` cannot say — that the list
+ * splits fleet-wide from per-feature, and that `next.recover-commit` outranks
+ * everything in both forms.
+ *
+ * Same assembly contract as every section: the composition concatenates with
+ * NO join separator, so this string starts at the first character of its
+ * opening line and ends with the newline that closes its last one.
+ */
+export const STATUS_COMMAND = `- \`loam status [<FEAT>]\` is the orientation surface — the question you have when
+  you join a repository halfway, or come back having lost the session, and the one
+  every other command assumed you could already answer. It writes nothing and
+  stores nothing: there is no state file, every answer is re-derived from the
+  files, so a document someone edited in another window is visible on the next run
+  with nothing to invalidate. Artifacts come back as \`missing\` (owed, nothing in
+  the way — write it now), \`blocked\` (not written and not writable yet; the entry
+  names what comes first), \`draft\` (on disk, and the shared checks report an error
+  against it — what exists is wrong), \`ready\` (on disk and clean, but something
+  outside the documents — code, a test run, a recording — still has to answer it)
+  or \`done\`. The payload's reason to exist is \`next[]\`: ordered, first entry
+  first, each carrying a code and the literal command to run — so a step needs no
+  gloss here, and \`loam explain <code>\` has the long form of any of them.
+  \`next.recover-commit\` outranks every other step in both forms below and is
+  never elided: a \`.loam-commit\` journal says a writer was killed mid-commit, so
+  some of the files everything else is derived from may be half-written.
+  Fleet-wide the rest are \`next.adopt-bound\`, \`next.adopt\`,
+  \`next.complete-service\`, \`next.feature\`, \`next.archive\`, \`next.fleet-clean\`,
+  \`next.elided\` (the fleet list hit its cap and says how many steps of the same
+  kinds it left out — it is ordered most-unblocking first, so work down it and
+  re-run) and \`next.fleet-gate\`, always last while anything is outstanding:
+  \`loam validate --all\` is what CI runs, and the fleet form grades nothing
+  itself. A docs repo with no services and no features instead gets the
+  first-hour ladder — \`next.author-landscape\`, \`next.bind-service\`,
+  \`next.adopt-first\` — which the \`/loam-adopt\` body walks.
+  On one feature: \`next.author-intent\`, \`next.touch-service\`,
+  \`next.author-spec\`, \`next.author-openapi\`, \`next.author-scenarios\`,
+  \`next.rebase\`, \`next.archive-first\`, \`next.fix-coherence\`,
+  \`next.generate-tests\`, \`next.verify\`, \`next.verify-unconfirmed\`,
+  \`next.attest-service\` (this repo IS one of the services that owes an answer,
+  so the step is bound to this commit), \`next.verify-attested\` — see
+  "The done-check" for what attested costs — \`next.archive\`, and
+  \`next.archived\` for one that shipped.
+  It grades nothing of its own: the verdict is the one \`loam validate --feature\`
+  and \`loam archive\` compute — status takes the UNION of what both of them refuse,
+  so it may be more pessimistic than either and can never be greener than both.
+  \`verification\` carries \`verdict\` (\`verified\` | \`attested\` | \`unverified\`)
+  and \`attested\` (how many scenario claims rest on an agent's word) beside the
+  recounted totals, and \`checks.issues[]\` carries \`gates\` and \`details\` on every
+  finding.
+`;
+//# sourceMappingURL=status.js.map

package/dist/core/agent/agents-md/map/status.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"status.js","sourceRoot":"","sources":["../../../../../src/core/agent/agents-md/map/status.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;GAmBG;AACH,MAAM,CAAC,MAAM,cAAc,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwC7B,CAAC","sourcesContent":["/**\n * The `loam status` entry of the command map — its own section module for\n * `./mcp.ts`'s exact reason: command-map.ts sat against the file-line limit,\n * so the orientation surface's documentation lives one package down. Unlike\n * its siblings it is not concatenated AFTER the map: status is deliberately\n * the map's FIRST bullet, so ../command-map.ts composes it into COMMAND_MAP\n * between the preamble and the validate entries. The `next.*` fleet and\n * feature codes are what test/codes-drift.test.ts finds here.\n *\n * The `next.*` codes are LISTED, not glossed: `loam explain next.adopt` (and\n * every sibling) answers what a step means and what to run, out of the binary\n * rather than out of this file. See ../command-map.ts's header for why the\n * gloss left. What survives here is what `explain` cannot say — that the list\n * splits fleet-wide from per-feature, and that `next.recover-commit` outranks\n * everything in both forms.\n *\n * Same assembly contract as every section: the composition concatenates with\n * NO join separator, so this string starts at the first character of its\n * opening line and ends with the newline that closes its last one.\n */\nexport const STATUS_COMMAND = `- \\`loam status [<FEAT>]\\` is the orientation surface — the question you have when\n  you join a repository halfway, or come back having lost the session, and the one\n  every other command assumed you could already answer. It writes nothing and\n  stores nothing: there is no state file, every answer is re-derived from the\n  files, so a document someone edited in another window is visible on the next run\n  with nothing to invalidate. Artifacts come back as \\`missing\\` (owed, nothing in\n  the way — write it now), \\`blocked\\` (not written and not writable yet; the entry\n  names what comes first), \\`draft\\` (on disk, and the shared checks report an error\n  against it — what exists is wrong), \\`ready\\` (on disk and clean, but something\n  outside the documents — code, a test run, a recording — still has to answer it)\n  or \\`done\\`. The payload's reason to exist is \\`next[]\\`: ordered, first entry\n  first, each carrying a code and the literal command to run — so a step needs no\n  gloss here, and \\`loam explain <code>\\` has the long form of any of them.\n  \\`next.recover-commit\\` outranks every other step in both forms below and is\n  never elided: a \\`.loam-commit\\` journal says a writer was killed mid-commit, so\n  some of the files everything else is derived from may be half-written.\n  Fleet-wide the rest are \\`next.adopt-bound\\`, \\`next.adopt\\`,\n  \\`next.complete-service\\`, \\`next.feature\\`, \\`next.archive\\`, \\`next.fleet-clean\\`,\n  \\`next.elided\\` (the fleet list hit its cap and says how many steps of the same\n  kinds it left out — it is ordered most-unblocking first, so work down it and\n  re-run) and \\`next.fleet-gate\\`, always last while anything is outstanding:\n  \\`loam validate --all\\` is what CI runs, and the fleet form grades nothing\n  itself. A docs repo with no services and no features instead gets the\n  first-hour ladder — \\`next.author-landscape\\`, \\`next.bind-service\\`,\n  \\`next.adopt-first\\` — which the \\`/loam-adopt\\` body walks.\n  On one feature: \\`next.author-intent\\`, \\`next.touch-service\\`,\n  \\`next.author-spec\\`, \\`next.author-openapi\\`, \\`next.author-scenarios\\`,\n  \\`next.rebase\\`, \\`next.archive-first\\`, \\`next.fix-coherence\\`,\n  \\`next.generate-tests\\`, \\`next.verify\\`, \\`next.verify-unconfirmed\\`,\n  \\`next.attest-service\\` (this repo IS one of the services that owes an answer,\n  so the step is bound to this commit), \\`next.verify-attested\\` — see\n  \"The done-check\" for what attested costs — \\`next.archive\\`, and\n  \\`next.archived\\` for one that shipped.\n  It grades nothing of its own: the verdict is the one \\`loam validate --feature\\`\n  and \\`loam archive\\` compute — status takes the UNION of what both of them refuse,\n  so it may be more pessimistic than either and can never be greener than both.\n  \\`verification\\` carries \\`verdict\\` (\\`verified\\` | \\`attested\\` | \\`unverified\\`)\n  and \\`attested\\` (how many scenario claims rest on an agent's word) beside the\n  recounted totals, and \\`checks.issues[]\\` carries \\`gates\\` and \\`details\\` on every\n  finding.\n`;\n"]}

package/dist/core/agent/agents-md/map/subsystem.js

@@ -0,0 +1,32 @@
+/**
+ * The `loam subsystem` half of the command map — its own section module
+ * because command-map.ts sat against the file-line limit and the agents-md
+ * package against the five-file cap, so the tree surface's documentation
+ * lives one package down and is concatenated after the map.
+ *
+ * Same assembly contract as every section: ../agents-md.ts concatenates with
+ * NO join separator, so this string starts at the first character of its
+ * opening line and ends with the newline that closes its last one.
+ */
+export const SUBSYSTEM_COMMANDS = `- \`loam subsystem <verb>\` manages the grouping tree under \`services/\` — the
+  navigable tree no identity depends on: a service id stays its leaf directory
+  name, every join key is byte-identical before and after a move, and the tree
+  carries no policy. Verbs: \`new <name> [--under <sub>] [--title] [--description]
+  [--owner]\` creates a group (an empty one is legal — its \`subsystem.yaml\` is a
+  marker, never a member list); \`move <name>... --into <sub|.>\` relocates
+  services and whole subtrees in ONE journaled transaction over the renames
+  plus the regenerated views file (\`--into .\` unfiles; the renames and the
+  regenerated views file are staged in git without committing, where git answers); \`rename <old> <new>\` renames a
+  group through the same transaction (services are never renamed — the id is
+  the identity); \`rm <name>\` removes an EMPTY group; \`list\` shows the tree
+  with member counts and the unfiled count (unfiled is permanent and normal —
+  a count, never a finding; \`loam list --json\` carries the same facts as
+  additive keys \`services[].subsystem\`, \`subsystems[]\` and
+  \`unfiledServices\`); \`history <name>\` asks git how a service or subsystem
+  moved and answers nothing — exit 0, no finding — when git will not say;
+  \`sync\` regenerates \`architecture/subsystems.likec4\`, the one repair for
+  \`subsystem.views-stale\`; a landscape view claiming a generated id is
+  \`subsystem.view-id-collision\`. \`loam adopt --subsystem <name>\` briefs a new
+  service's baseline directly into a group, so adoption need not land unfiled.
+`;
+//# sourceMappingURL=subsystem.js.map

package/dist/core/agent/agents-md/map/subsystem.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"subsystem.js","sourceRoot":"","sources":["../../../../../src/core/agent/agents-md/map/subsystem.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AACH,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;CAoBjC,CAAC","sourcesContent":["/**\n * The `loam subsystem` half of the command map — its own section module\n * because command-map.ts sat against the file-line limit and the agents-md\n * package against the five-file cap, so the tree surface's documentation\n * lives one package down and is concatenated after the map.\n *\n * Same assembly contract as every section: ../agents-md.ts concatenates with\n * NO join separator, so this string starts at the first character of its\n * opening line and ends with the newline that closes its last one.\n */\nexport const SUBSYSTEM_COMMANDS = `- \\`loam subsystem <verb>\\` manages the grouping tree under \\`services/\\` — the\n  navigable tree no identity depends on: a service id stays its leaf directory\n  name, every join key is byte-identical before and after a move, and the tree\n  carries no policy. Verbs: \\`new <name> [--under <sub>] [--title] [--description]\n  [--owner]\\` creates a group (an empty one is legal — its \\`subsystem.yaml\\` is a\n  marker, never a member list); \\`move <name>... --into <sub|.>\\` relocates\n  services and whole subtrees in ONE journaled transaction over the renames\n  plus the regenerated views file (\\`--into .\\` unfiles; the renames and the\n  regenerated views file are staged in git without committing, where git answers); \\`rename <old> <new>\\` renames a\n  group through the same transaction (services are never renamed — the id is\n  the identity); \\`rm <name>\\` removes an EMPTY group; \\`list\\` shows the tree\n  with member counts and the unfiled count (unfiled is permanent and normal —\n  a count, never a finding; \\`loam list --json\\` carries the same facts as\n  additive keys \\`services[].subsystem\\`, \\`subsystems[]\\` and\n  \\`unfiledServices\\`); \\`history <name>\\` asks git how a service or subsystem\n  moved and answers nothing — exit 0, no finding — when git will not say;\n  \\`sync\\` regenerates \\`architecture/subsystems.likec4\\`, the one repair for\n  \\`subsystem.views-stale\\`; a landscape view claiming a generated id is\n  \\`subsystem.view-id-collision\\`. \\`loam adopt --subsystem <name>\\` briefs a new\n  service's baseline directly into a group, so adoption need not land unfiled.\n`;\n"]}

package/dist/core/agent/agents-md/map/usecases.js

@@ -0,0 +1,60 @@
+/**
+ * The use-case axis of the command map — its own section module for
+ * `./subsystem.ts`'s exact reason: command-map.ts sat against the file-line
+ * limit and the agents-md package against the five-file cap, so a family added
+ * to the `validate --all` cross-check documents itself one package down and is
+ * concatenated after the map. The four `usecase.*` codes are what
+ * test/codes-drift.test.ts finds here.
+ *
+ * They are LISTED and not glossed: their fix rows live in the /loam-check
+ * table and `loam explain usecase.step-unbacked` prints them, so writing the
+ * meanings out again here is the duplication ../../command-map.ts's header
+ * describes. What stays is what `explain` does not say — how to opt a view in,
+ * and that an untagged dynamic view is never graded at all.
+ *
+ * Same assembly contract as every section: ../../agents-md.ts concatenates with
+ * NO join separator, so this string starts at the first character of its opening
+ * line and ends with the newline that closes its last one.
+ */
+export const USECASE_VIEWS = `- Business use cases are \`dynamic view\`s, and \`loam validate --all\` grades the
+  ones that opt in. Write the flow in a file of its own —
+  \`architecture/usecases/<name>.likec4\`, a \`views { }\` block over the landscape's
+  elements, which loam reads as ONE LikeC4 project together with the map — and
+  tag the view \`#cap-<capability>\` to have it graded. The tag spells a declared
+  capability id with every \`/\` flattened to \`-\` (a LikeC4 tag name cannot carry a
+  slash), and it must be declared as a \`tag\` in the one \`specification\` block the
+  project has, since LikeC4 refuses an undeclared tag. EITHER reserved prefix
+  opts a view in — a view carrying only \`#req-<requirement>\` is graded too, and
+  earns \`usecase.requirement-unresolved\` for the \`#cap-\` tag it is missing
+  rather than silence. An UNTAGGED dynamic view is somebody's hand-drawn diagram
+  and is never graded — that opt-in is what lets a fleet full of existing
+  diagrams upgrade without turning red, and \`loam validate\`, \`loam diff\`,
+  \`loam delta\`, \`loam status\`, \`loam context\` and \`loam list capabilities\` all
+  read the same opt-in, so a flow one of them sees is a flow all of them see. On a tagged
+  view: \`usecase.capability-unresolved\`, \`usecase.step-unbacked\`,
+  \`usecase.step-contested\` and \`usecase.step-unlinked\`. The first is silent
+  while architecture/capabilities.yaml is absent or unreadable, like the rest of
+  the capability axis; the three step codes are about the model, and a return
+  hop written \`a <- b\` is attributed to the call it answers, so spell replies
+  that way rather than as fresh hops. Every message names the file the view was
+  written in, never the landscape.
+- A FEATURE brings a flow the way it brings every other axis: write it at
+  \`features/<FEAT>/usecases/<name>.likec4\` — the same views-only document, in the
+  feature's own directory — and \`loam archive\` copies it into
+  \`architecture/usecases/\` while \`loam unarchive\` takes it back. That is what lets
+  an analyst add a cross-service requirement and an architect answer it with the
+  flow that keeps it IN ONE CHANGE: the \`#req-\` tag resolves against this
+  feature's own \`capabilities/<cap>/spec.md\` delta as well as the living tree, and
+  \`capability.uncovered\` counts the flow as cover. The flow is graded against the
+  map the same merge would leave behind, so a hop may name a service this
+  feature's \`delta.likec4\` adds. Two refusals guard it, and \`--approve\` moves
+  neither: \`usecase.flow-exists\` (the living \`architecture/usecases/\` already has
+  that file — the merge is a whole-file copy, so edit the living one directly
+  instead) and \`usecase.flow-invalid\` (loam could not read the flows against that
+  post-merge map — most often a hop naming an element neither the living
+  landscape nor the delta declares). Do NOT put a \`dynamic view\` inside
+  \`delta.likec4\`: that document re-declares the landscape's own identifiers and
+  carries its own \`specification\` block, so it cannot be read beside the map, and
+  the archive refuses it by name.
+`;
+//# sourceMappingURL=usecases.js.map

package/dist/core/agent/agents-md/map/usecases.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"usecases.js","sourceRoot":"","sources":["../../../../../src/core/agent/agents-md/map/usecases.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwC5B,CAAC","sourcesContent":["/**\n * The use-case axis of the command map — its own section module for\n * `./subsystem.ts`'s exact reason: command-map.ts sat against the file-line\n * limit and the agents-md package against the five-file cap, so a family added\n * to the `validate --all` cross-check documents itself one package down and is\n * concatenated after the map. The four `usecase.*` codes are what\n * test/codes-drift.test.ts finds here.\n *\n * They are LISTED and not glossed: their fix rows live in the /loam-check\n * table and `loam explain usecase.step-unbacked` prints them, so writing the\n * meanings out again here is the duplication ../../command-map.ts's header\n * describes. What stays is what `explain` does not say — how to opt a view in,\n * and that an untagged dynamic view is never graded at all.\n *\n * Same assembly contract as every section: ../../agents-md.ts concatenates with\n * NO join separator, so this string starts at the first character of its opening\n * line and ends with the newline that closes its last one.\n */\nexport const USECASE_VIEWS = `- Business use cases are \\`dynamic view\\`s, and \\`loam validate --all\\` grades the\n  ones that opt in. Write the flow in a file of its own —\n  \\`architecture/usecases/<name>.likec4\\`, a \\`views { }\\` block over the landscape's\n  elements, which loam reads as ONE LikeC4 project together with the map — and\n  tag the view \\`#cap-<capability>\\` to have it graded. The tag spells a declared\n  capability id with every \\`/\\` flattened to \\`-\\` (a LikeC4 tag name cannot carry a\n  slash), and it must be declared as a \\`tag\\` in the one \\`specification\\` block the\n  project has, since LikeC4 refuses an undeclared tag. EITHER reserved prefix\n  opts a view in — a view carrying only \\`#req-<requirement>\\` is graded too, and\n  earns \\`usecase.requirement-unresolved\\` for the \\`#cap-\\` tag it is missing\n  rather than silence. An UNTAGGED dynamic view is somebody's hand-drawn diagram\n  and is never graded — that opt-in is what lets a fleet full of existing\n  diagrams upgrade without turning red, and \\`loam validate\\`, \\`loam diff\\`,\n  \\`loam delta\\`, \\`loam status\\`, \\`loam context\\` and \\`loam list capabilities\\` all\n  read the same opt-in, so a flow one of them sees is a flow all of them see. On a tagged\n  view: \\`usecase.capability-unresolved\\`, \\`usecase.step-unbacked\\`,\n  \\`usecase.step-contested\\` and \\`usecase.step-unlinked\\`. The first is silent\n  while architecture/capabilities.yaml is absent or unreadable, like the rest of\n  the capability axis; the three step codes are about the model, and a return\n  hop written \\`a <- b\\` is attributed to the call it answers, so spell replies\n  that way rather than as fresh hops. Every message names the file the view was\n  written in, never the landscape.\n- A FEATURE brings a flow the way it brings every other axis: write it at\n  \\`features/<FEAT>/usecases/<name>.likec4\\` — the same views-only document, in the\n  feature's own directory — and \\`loam archive\\` copies it into\n  \\`architecture/usecases/\\` while \\`loam unarchive\\` takes it back. That is what lets\n  an analyst add a cross-service requirement and an architect answer it with the\n  flow that keeps it IN ONE CHANGE: the \\`#req-\\` tag resolves against this\n  feature's own \\`capabilities/<cap>/spec.md\\` delta as well as the living tree, and\n  \\`capability.uncovered\\` counts the flow as cover. The flow is graded against the\n  map the same merge would leave behind, so a hop may name a service this\n  feature's \\`delta.likec4\\` adds. Two refusals guard it, and \\`--approve\\` moves\n  neither: \\`usecase.flow-exists\\` (the living \\`architecture/usecases/\\` already has\n  that file — the merge is a whole-file copy, so edit the living one directly\n  instead) and \\`usecase.flow-invalid\\` (loam could not read the flows against that\n  post-merge map — most often a hop naming an element neither the living\n  landscape nor the delta declares). Do NOT put a \\`dynamic view\\` inside\n  \\`delta.likec4\\`: that document re-declares the landscape's own identifiers and\n  carries its own \\`specification\\` block, so it cannot be read beside the map, and\n  the archive refuses it by name.\n`;\n"]}