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

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

@@ -0,0 +1,44 @@
+/**
+ * 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 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
+ * 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 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\`
+  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. \`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.
+`;
+//# 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;;;;;;;;;;;;;;;;;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

@@ -0,0 +1,78 @@
+/**
+ * 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\`. 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, 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
+  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 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, 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

@@ -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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;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

@@ -0,0 +1,104 @@
+/**
+ * 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 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
+  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 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 —
+  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 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

@@ -0,0 +1 @@
+{"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"]}

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

@@ -0,0 +1,138 @@
+/**
+ * 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 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 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
+  \`architecture/\` project has, since LikeC4 refuses an undeclared tag. loam grades
+  the fleet map as THAT project and nothing else — the landscape plus its
+  siblings, never a service model — so a hop here names SERVICE elements: a step
+  naming a container that a service's extending model declares resolves in the
+  renderer's wider root project and is \`landscape.invalid\` for loam, which takes
+  the whole fleet map down. Container-level flows live beside the model that
+  declares them (below). ANY 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; so is a view carrying only \`#suite-<name>\` (below). 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\`, \`loam list capabilities\` and
+  \`loam list suites\` 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. Where the map joins one pair by several
+  edges naming different operations, open the step's title with the operation id
+  the hop means and then punctuation —
+  \`orders -> payments 'authorizePayment — authorizes the payment'\`
+  (or the message it publishes or consumes) — or the hop stays
+  \`usecase.step-contested\`: loam never picks one for you. Every message names
+  the file the view was written in, never the landscape.
+- A fleet flow says which test SUITES it runs in with \`#suite-<name>\` tags —
+  a separate prefix from \`#cap-\`, many-to-many (one view may carry several),
+  each declared as a \`tag suite-<name>\` in the landscape's \`specification\` so a
+  typo is a parse error. Tagging is the opt-in: a view carrying ONLY \`#suite-\`
+  tags is a use case and its hops are graded like any other's. To answer "which
+  services must be up for suite X", run \`loam list suites smoke --json\` (or
+  \`loam list suites --json\` for every suite): \`suites[]\` carries each suite's
+  \`views[]\` (\`id\`, \`file\`), \`services[]\` (enumerated service ids, through the
+  same element→service join the step grades use) and \`unresolved[]\` (\`element\`,
+  \`external\`) — participants no service stands for, never dropped, so a stand
+  that needs a double for them says so; \`ungrouped[]\` names the use cases in no
+  suite, and \`useCases.state\` is \`absent\`, \`ok\` or \`unreadable\` (with
+  \`error\`; \`suites\`/\`ungrouped\` are then absent, not empty). An unknown suite
+  name refuses \`unknown-target\` with close names. Only the fleet map's flows
+  are listed.
+- A flow behind ONE service's own requirement — the hop sequence over its
+  containers that an arch.spec.md \`Covers:\` names — lives in that service's own
+  LikeC4 project: any \`.likec4\` beside \`services/<…>/<svc>/model.likec4\`
+  (\`usecases/<name>.likec4\` by convention, or \`views.likec4\`), or a \`dynamic view\`
+  inside model.likec4 itself; loam reads exactly what the renderer's per-service
+  project reads. Never \`architecture/usecases/\`, which cannot resolve a container
+  and turns the whole fleet \`landscape.invalid\`. Tag it \`#req-<Requirement-ID>\`
+  (the id flattened as above). The tag has to be DECLARED where that project can
+  see it: in model.likec4's own \`specification\` block when the model declares one
+  and therefore stands alone; in \`architecture/landscape.likec4\`'s block when the
+  model EXTENDS the map, or in a tags-only \`specification { tag req-… }\` beside
+  the \`extend\`, which is legal and lands the tag in the project's specification.
+  Declaring it in BOTH is a duplicate, and the code is the one that lands where
+  the second declaration's FILE is: \`c4.invalid\` (an error, and the model's
+  grading is suspended behind it) when the tags-only block is in model.likec4,
+  \`usecase.flow-invalid\` when it is in a sibling. \`c4.fleet-project-invalid\` is
+  the fleet-scope class one step out — two SERVICES each declaring the same tag
+  locally, which no per-service project sees.
+  Then \`loam validate --service <svc>\` grades it — under
+  \`--all\`, per service: \`usecase.step-unbacked\` and \`usecase.step-contested\`
+  against model.likec4, \`usecase.requirement-unresolved\` against THIS service's
+  spec.md and arch.spec.md ids, and \`usecase.flow-invalid\` when a sibling file
+  breaks the project (model.likec4 is still graded alone). \`usecase.step-unlinked\`
+  never fires on a hop whose caller and provider resolve to the same service — a
+  service owes no operationId to itself — while a hop from such a flow into another
+  service's element (a stand-in the model declares for a sibling, with no
+  \`metadata { op }\`) still warns, exactly as on the fleet map. A \`#cap-\` tag on
+  such a flow is \`usecase.capability-unresolved\`: a capability is claimed on the
+  fleet map, never inside one service. A resolved service-local \`#req-\` keeps its
+  own grade and nothing else — it is not \`keptBy\`, not \`Covers:\`, and no feature
+  carries one yet.
+- A feature that MODIFIES a requirement a LIVING flow claims — an \`architecture/\`
+  flow's \`#req-\` tag on a capability requirement, or a service-local flow's on
+  that service's own — gets \`usecase.requirement-modified\` (warn, never gates)
+  wherever the feature is graded (\`loam validate --feature\`, \`--all\` per active
+  feature, \`loam status <FEAT>\`, the archive): the tag still resolves after
+  the merge, so nothing else would say the drawing now answers to new words.
+  Read the flow against the replacement and redraw it in the same change if it
+  no longer keeps the promise. A feature that REMOVES such a requirement gets
+  \`usecase.requirement-unresolved\` (error, gates, \`--approve\`-overridable) in
+  the same places, naming the living flow: the tag will resolve to nothing, and
+  \`validate --all\` would report exactly that after the archive. Drop the tag in
+  the same change, or MODIFY the requirement instead. A MODIFIED gets the same
+  error, not the warning, when an id the feature adds flattens to that tag.
+- 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; the merge preview stages no service model, so
+  a container an extending model declares is not among them either). 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. A feature's \`delta.likec4\` keeps that shape
+  whatever shape the service models take — \`features/**\` stays excluded from the
+  root LikeC4 project, and the delta is pointed at alone
+  (\`npx likec4 start features/<FEAT>\`).
+`;
+//# 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;;;;;;;;;;;;;;;;;;GAkBG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqH5B,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 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 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  \\`architecture/\\` project has, since LikeC4 refuses an undeclared tag. loam grades\n  the fleet map as THAT project and nothing else — the landscape plus its\n  siblings, never a service model — so a hop here names SERVICE elements: a step\n  naming a container that a service's extending model declares resolves in the\n  renderer's wider root project and is \\`landscape.invalid\\` for loam, which takes\n  the whole fleet map down. Container-level flows live beside the model that\n  declares them (below). ANY 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; so is a view carrying only \\`#suite-<name>\\` (below). An\n  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\\`, \\`loam list capabilities\\` and\n  \\`loam list suites\\` 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. Where the map joins one pair by several\n  edges naming different operations, open the step's title with the operation id\n  the hop means and then punctuation —\n  \\`orders -> payments 'authorizePayment — authorizes the payment'\\`\n  (or the message it publishes or consumes) — or the hop stays\n  \\`usecase.step-contested\\`: loam never picks one for you. Every message names\n  the file the view was written in, never the landscape.\n- A fleet flow says which test SUITES it runs in with \\`#suite-<name>\\` tags —\n  a separate prefix from \\`#cap-\\`, many-to-many (one view may carry several),\n  each declared as a \\`tag suite-<name>\\` in the landscape's \\`specification\\` so a\n  typo is a parse error. Tagging is the opt-in: a view carrying ONLY \\`#suite-\\`\n  tags is a use case and its hops are graded like any other's. To answer \"which\n  services must be up for suite X\", run \\`loam list suites smoke --json\\` (or\n  \\`loam list suites --json\\` for every suite): \\`suites[]\\` carries each suite's\n  \\`views[]\\` (\\`id\\`, \\`file\\`), \\`services[]\\` (enumerated service ids, through the\n  same element→service join the step grades use) and \\`unresolved[]\\` (\\`element\\`,\n  \\`external\\`) — participants no service stands for, never dropped, so a stand\n  that needs a double for them says so; \\`ungrouped[]\\` names the use cases in no\n  suite, and \\`useCases.state\\` is \\`absent\\`, \\`ok\\` or \\`unreadable\\` (with\n  \\`error\\`; \\`suites\\`/\\`ungrouped\\` are then absent, not empty). An unknown suite\n  name refuses \\`unknown-target\\` with close names. Only the fleet map's flows\n  are listed.\n- A flow behind ONE service's own requirement — the hop sequence over its\n  containers that an arch.spec.md \\`Covers:\\` names — lives in that service's own\n  LikeC4 project: any \\`.likec4\\` beside \\`services/<…>/<svc>/model.likec4\\`\n  (\\`usecases/<name>.likec4\\` by convention, or \\`views.likec4\\`), or a \\`dynamic view\\`\n  inside model.likec4 itself; loam reads exactly what the renderer's per-service\n  project reads. Never \\`architecture/usecases/\\`, which cannot resolve a container\n  and turns the whole fleet \\`landscape.invalid\\`. Tag it \\`#req-<Requirement-ID>\\`\n  (the id flattened as above). The tag has to be DECLARED where that project can\n  see it: in model.likec4's own \\`specification\\` block when the model declares one\n  and therefore stands alone; in \\`architecture/landscape.likec4\\`'s block when the\n  model EXTENDS the map, or in a tags-only \\`specification { tag req-… }\\` beside\n  the \\`extend\\`, which is legal and lands the tag in the project's specification.\n  Declaring it in BOTH is a duplicate, and the code is the one that lands where\n  the second declaration's FILE is: \\`c4.invalid\\` (an error, and the model's\n  grading is suspended behind it) when the tags-only block is in model.likec4,\n  \\`usecase.flow-invalid\\` when it is in a sibling. \\`c4.fleet-project-invalid\\` is\n  the fleet-scope class one step out — two SERVICES each declaring the same tag\n  locally, which no per-service project sees.\n  Then \\`loam validate --service <svc>\\` grades it — under\n  \\`--all\\`, per service: \\`usecase.step-unbacked\\` and \\`usecase.step-contested\\`\n  against model.likec4, \\`usecase.requirement-unresolved\\` against THIS service's\n  spec.md and arch.spec.md ids, and \\`usecase.flow-invalid\\` when a sibling file\n  breaks the project (model.likec4 is still graded alone). \\`usecase.step-unlinked\\`\n  never fires on a hop whose caller and provider resolve to the same service — a\n  service owes no operationId to itself — while a hop from such a flow into another\n  service's element (a stand-in the model declares for a sibling, with no\n  \\`metadata { op }\\`) still warns, exactly as on the fleet map. A \\`#cap-\\` tag on\n  such a flow is \\`usecase.capability-unresolved\\`: a capability is claimed on the\n  fleet map, never inside one service. A resolved service-local \\`#req-\\` keeps its\n  own grade and nothing else — it is not \\`keptBy\\`, not \\`Covers:\\`, and no feature\n  carries one yet.\n- A feature that MODIFIES a requirement a LIVING flow claims — an \\`architecture/\\`\n  flow's \\`#req-\\` tag on a capability requirement, or a service-local flow's on\n  that service's own — gets \\`usecase.requirement-modified\\` (warn, never gates)\n  wherever the feature is graded (\\`loam validate --feature\\`, \\`--all\\` per active\n  feature, \\`loam status <FEAT>\\`, the archive): the tag still resolves after\n  the merge, so nothing else would say the drawing now answers to new words.\n  Read the flow against the replacement and redraw it in the same change if it\n  no longer keeps the promise. A feature that REMOVES such a requirement gets\n  \\`usecase.requirement-unresolved\\` (error, gates, \\`--approve\\`-overridable) in\n  the same places, naming the living flow: the tag will resolve to nothing, and\n  \\`validate --all\\` would report exactly that after the archive. Drop the tag in\n  the same change, or MODIFY the requirement instead. A MODIFIED gets the same\n  error, not the warning, when an id the feature adds flattens to that tag.\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; the merge preview stages no service model, so\n  a container an extending model declares is not among them either). Do NOT put a\n  \\`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. A feature's \\`delta.likec4\\` keeps that shape\n  whatever shape the service models take — \\`features/**\\` stays excluded from the\n  root LikeC4 project, and the delta is pointed at alone\n  (\\`npx likec4 start features/<FEAT>\\`).\n`;\n"]}