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

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

@@ -6,9 +6,10 @@
  * 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.
+ * Same assembly contract as every part of the `loam-codes` page:
+ * ../../../workflows/reference/codes.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
@@ -16,9 +17,10 @@ export const CONTEXT_COMMAND = `- \`loam context <service>\` assembles the docs
   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
+  the map's own health beside them (\`landscape.present\` is the FILE,
+  \`landscape.parses\` is the whole \`architecture/\` project the renderer loads,
+  as \`loam adopt\` reads it — 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
@@ -29,8 +31,15 @@ export const CONTEXT_COMMAND = `- \`loam context <service>\` assembles the docs
   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
+  services list. A service an active feature INTRODUCES (its
+  \`features/<FEAT>/specs/<svc>/\` exists, \`services/<svc>/\` does not yet) is
+  briefed from that feature's delta: the payload carries \`living: false\` and
+  \`introducedBy\`, the living sections are empty, and \`path\` is the feature's
+  \`specs/<svc>/\`. Two features introducing the same service refuse with
+  \`invalid-option\` until \`--feature\` names one. \`loam show <svc>\` and
+  \`loam steps --service <svc>\` answer for such a service the same way, from
+  the delta and marked \`living: false\`. 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)

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

@@ -1 +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"]}
+{"version":3,"file":"context.js","sourceRoot":"","sources":["../../../../../../src/core/agent/agents-md/map/lenses/context.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AACH,MAAM,CAAC,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAmC9B,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 part of the `loam-codes` page:\n * ../../../workflows/reference/codes.ts concatenates with NO join separator,\n * so this string starts at the first character of its opening line and ends\n * 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\\` is the FILE,\n  \\`landscape.parses\\` is the whole \\`architecture/\\` project the renderer loads,\n  as \\`loam adopt\\` reads it — an empty edge list under a map that does not parse\n  is \"nobody could look\", never \"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. A service an active feature INTRODUCES (its\n  \\`features/<FEAT>/specs/<svc>/\\` exists, \\`services/<svc>/\\` does not yet) is\n  briefed from that feature's delta: the payload carries \\`living: false\\` and\n  \\`introducedBy\\`, the living sections are empty, and \\`path\\` is the feature's\n  \\`specs/<svc>/\\`. Two features introducing the same service refuse with\n  \\`invalid-option\\` until \\`--feature\\` names one. \\`loam show <svc>\\` and\n  \\`loam steps --service <svc>\\` answer for such a service the same way, from\n  the delta and marked \\`living: false\\`. Exit 1 with \\`ok: true\\` means a\n  document behind the pack did 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

@@ -12,35 +12,48 @@
  * 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.
+ * Same assembly contract as every part of the `loam-codes` page:
+ * ../../../workflows/reference/codes.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.
+  what a branch CHANGES, and names the authored consumers of every removal,
+  deprecation and modification.
   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.
+  \`diff.op-added\`, \`diff.op-removed\`, \`diff.op-removed-consumed\`,
+  \`diff.op-deprecated\` and \`diff.op-modified\` over the OpenAPI contract;
+  \`diff.message-added\`, \`diff.message-removed\`,
+  \`diff.message-removed-consumed\` and \`diff.message-modified\` 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[]\` — the same consumers \`loam archive\` refuses a removal on
+  (edges of the \`architecture/\` project, both spec files, use-case hops; a
+  line naming its own service's operation of the same id is no victim). The two contract \`-modified\` codes are warnings whoever
+  is joined: the operation or message changed — its own node or anything its
+  \`$ref\`s reach — and \`details[]\` names who to check it against, but loam
+  does not grade whether the change breaks them. A landscape edge into the
+  provider drawn with no \`metadata { op }\` is listed as a consumer nobody
+  could check, never dropped. 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". An unreadable openapi.yaml or asyncapi.yaml whose bytes
+  the base holds identically is skipped instead: the branch did not touch it.
+  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 breaking-change
+  catalogue, run oasdiff (OpenAPI) or \`asyncapi diff\` (AsyncAPI) 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

@@ -1 +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"]}
+{"version":3,"file":"diff.js","sourceRoot":"","sources":["../../../../../../src/core/agent/agents-md/map/lenses/diff.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AACH,MAAM,CAAC,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsC3B,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 part of the `loam-codes` page:\n * ../../../workflows/reference/codes.ts concatenates with NO join separator,\n * so this string starts at the first character of its opening line and ends\n * 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 the authored consumers of every removal,\n  deprecation and modification.\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\\`,\n  \\`diff.op-deprecated\\` and \\`diff.op-modified\\` over the OpenAPI contract;\n  \\`diff.message-added\\`, \\`diff.message-removed\\`,\n  \\`diff.message-removed-consumed\\` and \\`diff.message-modified\\` over the\n  AsyncAPI contract; and \\`diff.consumer-added\\` / \\`diff.consumer-removed\\`\n  over the cross-service joins — another service's requirement naming this\n  service's operation or message. The two \\`-consumed\\` codes are the errors:\n  they are the removals something in the fleet still names, with the victims\n  in \\`details[]\\` — the same consumers \\`loam archive\\` refuses a removal on\n  (edges of the \\`architecture/\\` project, both spec files, use-case hops; a\n  line naming its own service's operation of the same id is no victim). The two contract \\`-modified\\` codes are warnings whoever\n  is joined: the operation or message changed — its own node or anything its\n  \\`$ref\\`s reach — and \\`details[]\\` names who to check it against, but loam\n  does not grade whether the change breaks them. A landscape edge into the\n  provider drawn with no \\`metadata { op }\\` is listed as a consumer nobody\n  could check, never dropped. Exit 0 = diff computed, nothing breaking,\n  everything readable; exit 1 = a refusal, any error finding\n  (\\`breaking: true\\` in \\`--json\\`), or a subject whose artifact could not be\n  read on either side — those axes are SUSPENDED and reported (\\`unreadable\\`\n  in the payload and the summary), never graded as \"nothing changed\" or\n  \"everything added\". An unreadable openapi.yaml or asyncapi.yaml whose bytes\n  the base holds identically is skipped instead: the branch did not touch it.\n  Refusals reuse existing codes: \\`repository-unavailable\\`\n  when the docs repo has no git history to ask, and \\`unknown-target\\` when\n  \\`--base\\` resolves to no commit there. For the byte-level breaking-change\n  catalogue, run oasdiff (OpenAPI) or \\`asyncapi diff\\` (AsyncAPI) on the two\n  states of one contract instead — loam deliberately does not reimplement it.\n`;\n"]}

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

@@ -11,11 +11,12 @@
  * 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.
+ * Same assembly contract as every part of the `loam-codes` page:
+ * ../../../workflows/reference/codes.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
+export const GATE_COMMAND = `- \`loam gate [--service <id>] [--since <ref>]\` 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
@@ -40,6 +41,12 @@ export const GATE_COMMAND = `- \`loam gate [--service <id>]\` is the DEPLOY-pipe
   \`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\`.
+  Without \`--since\` that is in-flight features only — a feature leaves the
+  check the moment it is archived. \`--since <ref>\` (a docs-repo git ref: the
+  docs commit the last deploy recorded) also grades every feature archived
+  after it, under the same codes, its \`features[]\` row carrying
+  \`archived: true\`; it reads git as \`loam diff --base <ref>\` does and refuses
+  the same way when git cannot answer.
   \`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
@@ -47,7 +54,8 @@ export const GATE_COMMAND = `- \`loam gate [--service <id>]\` is the DEPLOY-pipe
   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\`
+  change under it. The payload carries \`since\` (\`{ ref, commit }\` or
+  null), \`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

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

@@ -1 +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"]}
+{"version":3,"file":"gate.js","sourceRoot":"","sources":["../../../../../../src/core/agent/agents-md/map/lenses/gate.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AACH,MAAM,CAAC,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6C3B,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 part of the `loam-codes` page:\n * ../../../workflows/reference/codes.ts concatenates with NO join separator,\n * so this string starts at the first character of its opening line and ends\n * with the newline that closes its last one.\n */\nexport const GATE_COMMAND = `- \\`loam gate [--service <id>] [--since <ref>]\\` 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  Without \\`--since\\` that is in-flight features only — a feature leaves the\n  check the moment it is archived. \\`--since <ref>\\` (a docs-repo git ref: the\n  docs commit the last deploy recorded) also grades every feature archived\n  after it, under the same codes, its \\`features[]\\` row carrying\n  \\`archived: true\\`; it reads git as \\`loam diff --base <ref>\\` does and refuses\n  the same way when git cannot answer.\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 \\`since\\` (\\`{ ref, commit }\\` or\n  null), \\`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

@@ -5,9 +5,10 @@
  * 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.
+ * Same assembly contract as every part of the `loam-codes` page:
+ * ../../workflows/reference/codes.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
@@ -15,9 +16,9 @@
  * 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
+export const MCP_COMMAND = `- \`loam mcp\` serves the sixteen base read commands — validate, status, list, show,
+  delta, tasks, diff, explore, dependencies, doctor, context, adopt, 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\`
@@ -33,7 +34,9 @@ export const MCP_COMMAND = `- \`loam mcp\` serves the fourteen base read command
   \`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
+  fetch the protocol its own skill points at. \`adopt\` is served because it
+  writes nothing: the loam-adopt protocol opens by running it, and its brief is
+  what the agent then writes from. 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.

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

@@ -1 +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"]}
+{"version":3,"file":"mcp.js","sourceRoot":"","sources":["../../../../../src/core/agent/agents-md/map/mcp.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AACH,MAAM,CAAC,MAAM,WAAW,GAAG;;;;;;;;;;;;;;;;;;;;;;;;CAwB1B,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 part of the `loam-codes` page:\n * ../../workflows/reference/codes.ts concatenates with NO join separator, so this\n * string starts at the first character of its opening line and ends with\n * 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 sixteen base read commands — validate, status, list, show,\n  delta, tasks, diff, explore, dependencies, doctor, context, adopt, gate, steps,\n  explain, 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. \\`adopt\\` is served because it\n  writes nothing: the loam-adopt protocol opens by running it, and its brief is\n  what the agent then writes from. 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

@@ -28,16 +28,29 @@ export const STATUS_COMMAND = `- \`loam status [<FEAT>]\` is the orientation sur
   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
+  or \`done\`. Those are values to branch on, not progress words: \`ready\` says
+  nothing about code being built or claims being verified, and an archived feature
+  is \`done\` whatever its record says — read \`verification\` for that. The human
+  view prints the stage in words with the claims counted, and the payload carries
+  \`feature.title\` and \`checklist.claims\` (what the checklist asks now; null once
+  archived). 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
+  Fleet-wide the rest are, in order, \`next.adopt-bound\` (or, when a feature in
+  flight introduces the service this repository is bound to, that feature's
+  \`next.feature\` instead — there is no code to adopt yet), every feature in
+  flight — \`next.feature\`, \`next.archive\` — and then each service's
+  adoption rungs: \`next.adopt\`, \`next.complete-service\`, \`next.revouch\` (a
+  vouched document's words moved under its stamp — \`content.stale\`; its
+  \`execution\` is a human review, never yours to run: prepare
+  \`loam vouch --pack --service <id>\` and hand the vouch to a person), every one
+  of them also listed uncapped in \`serviceSteps[]\` grouped by code; then
+  \`next.fleet-clean\`,
+  \`next.elided\` (the fleet list hit its cap and says how many steps of which
+  codes 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
@@ -50,13 +63,16 @@ export const STATUS_COMMAND = `- \`loam status [<FEAT>]\` is the orientation sur
   \`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.
+  \`next.archived\` for one that is archived (archive checks documents, not
+  code: the step says whether it was ever verified).
   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.
+  recounted totals, plus \`answered\` (the confirmed claims per \`answered_by\`:
+  \`runner\`, \`external-runner\`, \`agent\` — a \`verified\` record can still rest
+  partly on an agent's word about kinds the verdict does not turn on), and
+  \`checks.issues[]\` carries \`gates\` and \`details\` on every finding.
 `;
 //# sourceMappingURL=status.js.map

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

@@ -1 +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"]}
+{"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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwD7B,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\\`. Those are values to branch on, not progress words: \\`ready\\` says\n  nothing about code being built or claims being verified, and an archived feature\n  is \\`done\\` whatever its record says — read \\`verification\\` for that. The human\n  view prints the stage in words with the claims counted, and the payload carries\n  \\`feature.title\\` and \\`checklist.claims\\` (what the checklist asks now; null once\n  archived). 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, in order, \\`next.adopt-bound\\` (or, when a feature in\n  flight introduces the service this repository is bound to, that feature's\n  \\`next.feature\\` instead — there is no code to adopt yet), every feature in\n  flight — \\`next.feature\\`, \\`next.archive\\` — and then each service's\n  adoption rungs: \\`next.adopt\\`, \\`next.complete-service\\`, \\`next.revouch\\` (a\n  vouched document's words moved under its stamp — \\`content.stale\\`; its\n  \\`execution\\` is a human review, never yours to run: prepare\n  \\`loam vouch --pack --service <id>\\` and hand the vouch to a person), every one\n  of them also listed uncapped in \\`serviceSteps[]\\` grouped by code; then\n  \\`next.fleet-clean\\`,\n  \\`next.elided\\` (the fleet list hit its cap and says how many steps of which\n  codes 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 is archived (archive checks documents, not\n  code: the step says whether it was ever verified).\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, plus \\`answered\\` (the confirmed claims per \\`answered_by\\`:\n  \\`runner\\`, \\`external-runner\\`, \\`agent\\` — a \\`verified\\` record can still rest\n  partly on an agent's word about kinds the verdict does not turn on), and\n  \\`checks.issues[]\\` carries \\`gates\\` and \\`details\\` on every finding.\n`;\n"]}

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

@@ -4,9 +4,10 @@
  * 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.
+ * Same assembly contract as every part of the `loam-codes` page:
+ * ../../workflows/reference/codes.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
@@ -15,8 +16,8 @@ export const SUBSYSTEM_COMMANDS = `- \`loam subsystem <verb>\` manages the group
   [--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
+  plus BOTH regenerated views files (\`--into .\` unfiles; the renames and the
+  regenerated views files 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 —
@@ -24,9 +25,80 @@ export const SUBSYSTEM_COMMANDS = `- \`loam subsystem <verb>\` manages the group
   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
+  \`sync\` regenerates BOTH generated views files —
+  \`architecture/subsystems.likec4\` (one view per subsystem) and
+  \`architecture/services.likec4\` (one overview view per service the fleet map
+  draws) — the one repair for \`subsystem.views-stale\`, which grades each file
+  separately and names the one that drifted. It also maintains the RENDERER's
+  wiring for the service models. Which wiring a model needs is decided by the file's own
+  grammar, never by a config key: a model that declares its own
+  \`specification { element … }\` block STANDS ALONE — it cannot share a project
+  with the fleet map, since every kind it declares would be a duplicate there —
+  and a model with no such block EXTENDS the map with
+  \`extend <fully-qualified id> { … }\` and parses only INSIDE the root project.
+  So \`sync\` writes one create-only \`services/<…>/<id>/likec4.config.json\` per
+  STANDALONE model (never rewritten; the team may edit it; commit
+  the new files before a \`move\`, which refuses over untracked paths), DELETES one
+  sitting beside an EXTENDING model (that nested project claims the model out of
+  the root project, so \`likec4 validate .\` refuses without \`--project\` and,
+  wherever that project claims the model, \`export json --project fleet\` loses
+  the service's containers; \`--json\` lists what it removed as \`projects.removed\`), and rewrites
+  the root \`likec4.config.json\`'s \`exclude\` to hold \`services/<tree>/**\` for
+  exactly those models, keeping every entry that is not about \`services/\` in the
+  order the team wrote it. It rewrites that list when at least one extending model
+  exists, or when a standalone model's directory is not covered — an older repo
+  whose models all stand alone behind \`services/**\` is never touched. \`--json\`
+  carries the result as \`projects.exclude\`, and the text view prints one line when
+  it rewrote. Between them these repair four warnings:
+  \`service.likec4-config-missing\` (a standalone model with no project file),
+  \`service.likec4-config-stray\` (a project file beside an extending model),
+  \`service.model-excluded\` (an extending model the root \`exclude\` hides from the
+  renderer) and \`service.model-unexcluded\` (a standalone model it does not hide,
+  which blanks the whole root project). A flat fleet with no subsystems still owes
+  this run: the verb is the tree's, the files are the renderer's. A fleet whose
+  models all extend the map ends with ONE project and one picker entry, and
+  \`likec4 validate\` at the docs root needs no flag; each standalone model adds a
+  project, and with more than one \`likec4 validate\` needs \`--project <name>\`
+  (\`build\` and \`export\` take every project). A view id claimed twice inside one
+  project — the landscape and an extending model both minting it, or either
+  claiming a generated one — is
+  \`subsystem.view-id-collision\` — ids beginning \`subsystem_\` or \`service_\` are
+  loam's to mint. Each generated view is titled by its PATH —
+  every marked ancestor's label and its own, which the renderer reads as
+  folders — where a label is the marker's \`title\` or the directory name; the
+  marker's \`description\` rides along. A per-service view is titled
+  \`<subsystem path> / <service id>\`, so it lands in the same folder as its
+  group, and a \`dynamic view\` you write under
+  \`services/<…>/<id>/usecases/\` titled \`<subsystem path> / <service id> / <use
+  case>\` lands beside it. So editing \`subsystem.yaml\` changes
+  what the renderer LABELS the group, a parent's title changes every view
+  beneath it, and either makes both files stale until the next \`sync\`. Neither
+  generated file is part of the fleet-project load
+  (\`c4.fleet-project-invalid\` reads every other \`.likec4\` the root project holds);
+  \`subsystem.views-stale\` is the only check that reads them, by content
+  comparison against the deterministic re-render, never by reading what a view
+  shows. Each per-service view is declared \`of\` its service's element, which is
+  what makes every other view — the fleet map, its subsystem view, its peers'
+  views — drill into it with no authored link. Each subsystem view
+  carries \`global style subsystems\` — written after its title, the one line
+  LikeC4 gives a view for borrowing a palette — exactly when the \`architecture/\`
+  project declares a global style with that id (\`global { styleGroup subsystems
+  { style element.tag = #external { color gray } } }\`, in the landscape or in
+  ANY \`.likec4\` under \`architecture/\` the root \`exclude\` does not cover — a
+  \`palette.likec4\` beside the map counts); nothing otherwise, and loam never reads
+  what the group says. Declaring it is the whole opt-in and makes the file stale
+  once, until the next \`sync\`. When the project declares style groups under other
+  names only, the file opens with one comment line naming them and saying none is
+  \`subsystems\`, and the views carry the renderer's defaults — so declaring a group
+  under ANY name restales the file, because that comment is part of the bytes.
+  \`architecture/services.likec4\` reads a group named \`services\` the same way.
+  \`sync\` refuses to rewrite either file while \`architecture/\` does not parse
+  (\`action: "blocked"\`): fix the map first. Both are generated wholesale:
+  an authored diagram of the same services belongs in the landscape or in a
+  file of your own name, never here, and never as a \`view … of\` a subsystem or
+  service element, which would take the drill-down from these views
+  (\`loam instructions loam-drawing\` has the views that read). \`--json\` reports the subsystem file as
+  \`path\`/\`action\` and the per-service one as \`serviceViews\`. \`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

@@ -1 +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"]}
+{"version":3,"file":"subsystem.js","sourceRoot":"","sources":["../../../../../src/core/agent/agents-md/map/subsystem.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AACH,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA2FjC,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 part of the `loam-codes` page:\n * ../../workflows/reference/codes.ts concatenates with NO join separator, so this\n * string starts at the first character of its opening line and ends with\n * 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 BOTH regenerated views files (\\`--into .\\` unfiles; the renames and the\n  regenerated views files 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 BOTH generated views files —\n  \\`architecture/subsystems.likec4\\` (one view per subsystem) and\n  \\`architecture/services.likec4\\` (one overview view per service the fleet map\n  draws) — the one repair for \\`subsystem.views-stale\\`, which grades each file\n  separately and names the one that drifted. It also maintains the RENDERER's\n  wiring for the service models. Which wiring a model needs is decided by the file's own\n  grammar, never by a config key: a model that declares its own\n  \\`specification { element … }\\` block STANDS ALONE — it cannot share a project\n  with the fleet map, since every kind it declares would be a duplicate there —\n  and a model with no such block EXTENDS the map with\n  \\`extend <fully-qualified id> { … }\\` and parses only INSIDE the root project.\n  So \\`sync\\` writes one create-only \\`services/<…>/<id>/likec4.config.json\\` per\n  STANDALONE model (never rewritten; the team may edit it; commit\n  the new files before a \\`move\\`, which refuses over untracked paths), DELETES one\n  sitting beside an EXTENDING model (that nested project claims the model out of\n  the root project, so \\`likec4 validate .\\` refuses without \\`--project\\` and,\n  wherever that project claims the model, \\`export json --project fleet\\` loses\n  the service's containers; \\`--json\\` lists what it removed as \\`projects.removed\\`), and rewrites\n  the root \\`likec4.config.json\\`'s \\`exclude\\` to hold \\`services/<tree>/**\\` for\n  exactly those models, keeping every entry that is not about \\`services/\\` in the\n  order the team wrote it. It rewrites that list when at least one extending model\n  exists, or when a standalone model's directory is not covered — an older repo\n  whose models all stand alone behind \\`services/**\\` is never touched. \\`--json\\`\n  carries the result as \\`projects.exclude\\`, and the text view prints one line when\n  it rewrote. Between them these repair four warnings:\n  \\`service.likec4-config-missing\\` (a standalone model with no project file),\n  \\`service.likec4-config-stray\\` (a project file beside an extending model),\n  \\`service.model-excluded\\` (an extending model the root \\`exclude\\` hides from the\n  renderer) and \\`service.model-unexcluded\\` (a standalone model it does not hide,\n  which blanks the whole root project). A flat fleet with no subsystems still owes\n  this run: the verb is the tree's, the files are the renderer's. A fleet whose\n  models all extend the map ends with ONE project and one picker entry, and\n  \\`likec4 validate\\` at the docs root needs no flag; each standalone model adds a\n  project, and with more than one \\`likec4 validate\\` needs \\`--project <name>\\`\n  (\\`build\\` and \\`export\\` take every project). A view id claimed twice inside one\n  project — the landscape and an extending model both minting it, or either\n  claiming a generated one — is\n  \\`subsystem.view-id-collision\\` — ids beginning \\`subsystem_\\` or \\`service_\\` are\n  loam's to mint. Each generated view is titled by its PATH —\n  every marked ancestor's label and its own, which the renderer reads as\n  folders — where a label is the marker's \\`title\\` or the directory name; the\n  marker's \\`description\\` rides along. A per-service view is titled\n  \\`<subsystem path> / <service id>\\`, so it lands in the same folder as its\n  group, and a \\`dynamic view\\` you write under\n  \\`services/<…>/<id>/usecases/\\` titled \\`<subsystem path> / <service id> / <use\n  case>\\` lands beside it. So editing \\`subsystem.yaml\\` changes\n  what the renderer LABELS the group, a parent's title changes every view\n  beneath it, and either makes both files stale until the next \\`sync\\`. Neither\n  generated file is part of the fleet-project load\n  (\\`c4.fleet-project-invalid\\` reads every other \\`.likec4\\` the root project holds);\n  \\`subsystem.views-stale\\` is the only check that reads them, by content\n  comparison against the deterministic re-render, never by reading what a view\n  shows. Each per-service view is declared \\`of\\` its service's element, which is\n  what makes every other view — the fleet map, its subsystem view, its peers'\n  views — drill into it with no authored link. Each subsystem view\n  carries \\`global style subsystems\\` — written after its title, the one line\n  LikeC4 gives a view for borrowing a palette — exactly when the \\`architecture/\\`\n  project declares a global style with that id (\\`global { styleGroup subsystems\n  { style element.tag = #external { color gray } } }\\`, in the landscape or in\n  ANY \\`.likec4\\` under \\`architecture/\\` the root \\`exclude\\` does not cover — a\n  \\`palette.likec4\\` beside the map counts); nothing otherwise, and loam never reads\n  what the group says. Declaring it is the whole opt-in and makes the file stale\n  once, until the next \\`sync\\`. When the project declares style groups under other\n  names only, the file opens with one comment line naming them and saying none is\n  \\`subsystems\\`, and the views carry the renderer's defaults — so declaring a group\n  under ANY name restales the file, because that comment is part of the bytes.\n  \\`architecture/services.likec4\\` reads a group named \\`services\\` the same way.\n  \\`sync\\` refuses to rewrite either file while \\`architecture/\\` does not parse\n  (\\`action: \"blocked\"\\`): fix the map first. Both are generated wholesale:\n  an authored diagram of the same services belongs in the landscape or in a\n  file of your own name, never here, and never as a \\`view … of\\` a subsystem or\n  service element, which would take the drill-down from these views\n  (\\`loam instructions loam-drawing\\` has the views that read). \\`--json\\` reports the subsystem file as\n  \\`path\\`/\\`action\\` and the per-service one as \\`serviceViews\\`. \\`loam adopt --subsystem <name>\\` briefs a new\n  service's baseline directly into a group, so adoption need not land unfiled.\n`;\n"]}