aw-spec-cli 0.1.33 → 0.1.34

package/assets/.appweaver/orchestrator/modules/tech-select.orch.yaml

@@ -21,6 +21,15 @@
 # (referred to directly, as-is — NOT mapped) plus the caller's minimal seed, so an
 # unconfigured / greenfield project is never blocked. This keeps greenfield-safety.
 #
+# SOFT, NOT SILENT. Where a map exists but loads less than it says, the module WARNS
+# and carries on: the map has no `## /{{command}}` heading (absent or misspelled — a
+# heading that is present and deliberately empty does not warn), a mapped file is not on
+# disk, or a bullet uses a placeholder the kit does not know. The engine returns each
+# warning in the run result, so the operator sees it even though the run continues.
+# A stack with NO rule folder under guardrails/technology/ is reported once, as that
+# folder: it is a supported setup (STACK-PROFILES.md §7) that select-stack already
+# reported, not a list of typos. Files missing from a folder that exists are listed.
+#
 # Runs in the CALLER's context: shares vars + standards + the caller's `scripts:`
 # map + replay cache (include semantics). HITL steps suspend via the checkpoint
 # channel under every strategy; non-interactive default: selection → all.
@@ -52,11 +61,60 @@ workflow:
     outputs:
       - { name: tech_domain,        from: "$.domain" }
       - { name: tg_techmap_exists,  from: "$.techrulemap_exists" }
+      - { name: tg_heading_found,   from: "$.heading_found" }
       - { name: tg_candidates,      from: "$.candidates" }
+      - { name: tg_missing,         from: "$.missing_elsewhere" }
+      - { name: tg_absent,          from: "$.absent_corpora" }
+      - { name: tg_absent_text,     from: "$.absent_corpora_text" }
+      - { name: tg_absent_files,    from: "$.absent_files" }
+      - { name: tg_unknown,         from: "$.unknown_placeholders" }
       - { name: tg_mismatch,        from: "$.stack_mismatch" }
       - { name: tg_mismatched,      from: "$.mismatched_stacks" }
       - { name: tg_declared_stacks, from: "$.declared_stacks" }
 
+  # 1b. WHAT THE MAP SAYS AND DOES NOT LOAD — warnings, never stops. Each fires only where
+  #     the map exists; with no map at all there is nothing to misread. The engine has no
+  #     "list is not empty" test, so each list sets a flag false when it has entries.
+  - id: tg_flags
+    action: set
+    vars: { tg_all_on_disk: "true", tg_placeholders_known: "true", tg_corpora_present: "true" }
+  - id: tg_flag_missing
+    condition: "{{tg_missing}} != []"
+    action: set
+    vars: { tg_all_on_disk: "false" }
+  - id: tg_flag_absent
+    condition: "{{tg_absent}} != []"
+    action: set
+    vars: { tg_corpora_present: "false" }
+  - id: tg_flag_unknown
+    condition: "{{tg_unknown}} != []"
+    action: set
+    vars: { tg_placeholders_known: "false" }
+  - id: warn_no_heading
+    condition: "{{tg_techmap_exists}} == true"
+    action: verify_context
+    require_true: tg_heading_found
+    on_false: continue
+    on_false_message: "WARNING — guardrails/{{tech_domain}}/tech-rule-bindings.md has no `## /{{command}}` heading, so this step loads no technical rules from the map. If that is not intended, add the heading and its rule files — it must read exactly `## /{{command}}`."
+  - id: warn_absent_corpus
+    condition: "{{tg_techmap_exists}} == true"
+    action: verify_context
+    require_true: tg_corpora_present
+    on_false: continue
+    on_false_message: "WARNING — no technical rule set for {{tg_absent_text}} (the folder is not there), so the {{tg_absent_files}} file(s) guardrails/{{tech_domain}}/tech-rule-bindings.md maps there under `## /{{command}}` were not loaded. A stack without a rule set is supported: this step works from ai-rules.md and the technical constitution. To give the lane stack rules, write that folder with the file names the map lists, or point the map at your own files."
+  - id: warn_missing
+    condition: "{{tg_techmap_exists}} == true"
+    action: verify_context
+    require_true: tg_all_on_disk
+    on_false: continue
+    on_false_message: "WARNING — guardrails/{{tech_domain}}/tech-rule-bindings.md maps these files under `## /{{command}}`, but they are not on disk, so they were not loaded: {{tg_missing}}. Correct the paths, or add the files."
+  - id: warn_unknown_placeholder
+    condition: "{{tg_techmap_exists}} == true"
+    action: verify_context
+    require_true: tg_placeholders_known
+    on_false: continue
+    on_false_message: "WARNING — these bullets under `## /{{command}}` in guardrails/{{tech_domain}}/tech-rule-bindings.md use a placeholder the kit does not know, so they were not loaded: {{tg_unknown}}. The known placeholders are backend_stack, frontend_stack, stack, backend_ecosystem and frontend_ecosystem, each in double braces."
+
   # 1a. STACK MISMATCH — the map points at a technical corpus for a stack this repo
   #     does not declare. These files become STICKY STANDARDS: the generator obeys
   #     them for the rest of the run, so a Spring repo mapped to the .NET corpus is

package/assets/.appweaver/orchestrator/orchestrator.py

@@ -240,6 +240,11 @@ class Orchestrator:
         # paths an agent_generate reply named as written that were not on disk —
         # run-cumulative, reported at the end beside missing_required.
         self.reported_missing = []
+        # the messages of gates that failed and let the run CONTINUE — distinct, in
+        # order, returned in the run result. Under --json the run log is not printed,
+        # so this list is the only way a warning reaches the operator. A resumed run
+        # replays from the top, which rebuilds the list rather than doubling it.
+        self.warnings = []
         # agent_author targets a --dry-run left unwritten; required_files gates
         # count them as present, so a dry run reaches the steps after them.
         self.dry_run_unwritten = []
@@ -1049,23 +1054,29 @@ class Orchestrator:
         self.emit(f"[execute_script] -> {json.dumps(data)[:200]}")
 
     # -- F2: gates ---------------------------------------------------------------
-    def _gate_failed(self, p, outcome, msg):
+    def _gate_failed(self, p, outcome, msg, explicit=True):
         """Apply a failed gate's outcome: `stop` ends the skill, `return` ends the module
         being included (see Return), anything else continues. `message_var` binds the
         resolved message first, so a caller that continues or returns can still report
-        why — a message that only reaches the run log is not seen by the operator."""
+        why — a message that only reaches the run log is not seen by the operator.
+        A gate that continues with a message of its own (`explicit`) and no
+        `message_var` adds it to the run's `warnings`; a gate with `message_var`
+        reports through the variable instead."""
         if p.get("message_var"):
             self.vars[p["message_var"]] = msg
         if outcome == "stop":
             raise Stop(msg)
         if outcome == "return":
             raise Return(msg)
+        if explicit and not p.get("message_var") and msg not in self.warnings:
+            self.warnings.append(msg)
 
     def act_verify_context(self, step):
         """F2 — the four decl gate forms: required_files (+allow_missing),
         require_non_empty (+on_empty), require_true (+on_false),
         require_value/equals (+on_mismatch). Messages interpolate {{vars}}.
-        Outcomes: stop | return | continue; `message_var` binds a failed gate's message."""
+        Outcomes: stop | return | continue; `message_var` binds a failed gate's message,
+        and a continued gate's own message is otherwise collected into `warnings`."""
         p = step.get("parameters") or step
         if p.get("require_non_empty"):
             var = p["require_non_empty"]
@@ -1073,7 +1084,7 @@ class Orchestrator:
             if not val:
                 msg = self.resolve(p.get("on_empty_message", f"{var} is empty"))
                 self.emit(f"[verify_context] {var} is empty: {msg}")
-                self._gate_failed(p, p.get("on_empty"), msg)
+                self._gate_failed(p, p.get("on_empty"), msg, "on_empty_message" in p)
             else:
                 self.emit(f"[verify_context] {var} non-empty")
         if p.get("require_true"):
@@ -1084,7 +1095,7 @@ class Orchestrator:
             if not truthy:
                 msg = self.resolve(p.get("on_false_message", f"{var} is not satisfied"))
                 self.emit(f"[verify_context] gate failed ({var}): {msg}")
-                self._gate_failed(p, p.get("on_false", "stop"), msg)
+                self._gate_failed(p, p.get("on_false", "stop"), msg, "on_false_message" in p)
             else:
                 self.emit(f"[verify_context] gate ok ({var})")
         if p.get("require_value"):
@@ -1094,7 +1105,7 @@ class Orchestrator:
             if actual != expected:
                 msg = self.resolve(p.get("on_mismatch_message", f"{var} != {expected}"))
                 self.emit(f"[verify_context] value gate failed ({var}={actual!r}): {msg}")
-                self._gate_failed(p, p.get("on_mismatch", "stop"), msg)
+                self._gate_failed(p, p.get("on_mismatch", "stop"), msg, "on_mismatch_message" in p)
             else:
                 self.emit(f"[verify_context] value gate ok ({var}=={expected})")
         for rf in p.get("required_files", []) or []:
@@ -1585,7 +1596,8 @@ class Orchestrator:
             self.emit(f"[return] workflow ended early: {str(r)[:200]}")
         return {"status": "ok", "outputs": self.resolve(self.wf.get("outputs", {}) or {}),
                 "vars": self.vars, "missing_required": list(self.missing_required),
-                "reported_not_written": list(self.reported_missing)}
+                "reported_not_written": list(self.reported_missing),
+                "warnings": list(self.warnings)}
 
 
 # ─────────────────────────────────────────────────────────────────────────────
@@ -2086,7 +2098,8 @@ def main(argv=None):
     except Stop as e:
         result = {"status": "stopped", "reason": str(e), "vars": orch.vars,
                   "missing_required": list(orch.missing_required),
-                  "reported_not_written": list(orch.reported_missing)}
+                  "reported_not_written": list(orch.reported_missing),
+                  "warnings": list(orch.warnings)}
         _clear_checkpoint(opts)
 
     if opts.json:
@@ -2110,6 +2123,11 @@ def main(argv=None):
                   "later step read them:")
             for m in result["reported_not_written"]:
                 print(f"  - {m}")
+        if result.get("warnings"):
+            print(f"\nWARNING: {len(result['warnings'])} warning(s) from gates that let "
+                  "the run continue:")
+            for w in result["warnings"]:
+                print(f"  - {w}")
         if result.get("outputs"):
             print(json.dumps(result["outputs"], indent=2))
     return 0 if result["status"] == "ok" else 1

package/assets/.appweaver/orchestrator/rev-templates/delta-design-template.skeleton.md

@@ -26,7 +26,11 @@
     • ONE MASTER PER LANE — a change is planned against
       specs/<Context>/<Feature>/backend-plan.md; it never opens a second plan
       document and never edits the master. Neither does finalize-delta: the
-      master is re-derived from the merged spec and model by `plan main`.
+      master is re-derived from the merged spec, model and API plan by `plan main`.
+    • THE CHANGE'S API IS NOT PLANNED HERE — its endpoints and the requests it
+      answers are in delta-api-plan.md beside this file, from the kit's
+      delta-api-plan-template, the same in every project. This document plans
+      what realises them.
     • ADDED / MODIFIED / REMOVED — the complete classification. A shared element
       is MODIFIED in place, never duplicated into the change.
     • EVERY ROW SERVES A SPEC ID — the delta reads the delta-spec and the domain
@@ -53,13 +57,15 @@
 
 **Model delta**: `specs/[Context]/domain-model.[CR-ID].delta.md`   <!-- "none" when behaviour-only -->
 
+**API delta**: `changes/[CR-ID]/delta-api-plan.md`   <!-- the endpoints this change adds, changes or removes, which this plan realises -->
+
 <!--
   This delta applies to the SINGLE master plan at
   specs/[Context]/[Feature]/backend-plan.md — never a new plan doc. It does not
   touch the master, and neither does finalize-delta: the master is DERIVED from
-  spec.md and domain-model.md, the two documents finalize-delta merges, so
-  `plan main` re-derives it rather than patching it from this file. close-delta
-  archives this document as the record of how the change was built.
+  spec.md, domain-model.md and api-plan.md, the documents finalize-delta merges,
+  so `plan main` re-derives it rather than patching it from this file.
+  close-delta archives this document as the record of how the change was built.
 
   IT PLANS AGAINST THE EFFECTIVE MODEL — the master domain-model.md, this change's
   own model delta, and the PREDECESSOR deltas (the open ones in a LOWER wave,
@@ -124,21 +130,14 @@
 [Which of the master's sections ripple; shared elements touched; whether a data
 migration is needed (yes/no); any contract change other systems couple to.]
 
-## Contract deltas for the frontend lane
+## API changes
 
-<!-- What this change adds to, alters in or removes from the service's PUBLISHED
-     surface — the only part of this document the frontend lane may bind against.
-     `None` when the surface is unchanged. Omit the section entirely where the code
-     has no frontend lane. The operation id is the endpoint's name in the published
-     API document; an endpoint that already has one keeps it. A `changed` or
-     `removed` row whose operation the frontend plan binds to is reported by
-     analyze-plan-delta (contract-impact reads the Operation id and Change
-     columns) until the frontend delta of this change — or a follow-up change —
-     carries the matching change. -->
+<!-- The endpoints this change adds, changes or removes — its Contract deltas table and
+     their blocks — and the frontend lane's requests it answers are in delta-api-plan.md,
+     beside this file, not here. Keep this section as the one line below; omit it where the
+     code publishes no endpoint. -->
 
-| Operation id | Contract | Change | Shape | Serves |
-|---|---|---|---|---|
-| `[OperationId]` | `[contract]` | [added / changed / removed] | [request → response field shapes] | IC-[nnn] |
+The endpoints this change adds, changes or removes, and the requests it answers, are in [delta-api-plan.md](delta-api-plan.md).
 
 ## Other open deltas
 
@@ -164,8 +163,9 @@ changed.]
 ## On merge
 
 `finalize-delta` merges the change's SPEC half into `spec.md` and its MODEL half into the
-context's `domain-model.md`, in one transaction, and leaves the change OPEN. It does NOT
-merge this document: the master plan is derived from those two, so `plan main` re-derives
-it rather than patching it. `close-delta` archives this file with the change, bumps the
+context's `domain-model.md`, in one transaction, merges its `delta-api-plan.md` into the
+feature's `api-plan.md` by script, and leaves the change OPEN. It does NOT merge this
+document: the master plan is derived from those three, so `plan main` re-derives it rather
+than patching it. `close-delta` archives this file with the change, bumps the
 minor version and writes the Change History rows. None of it is this document's job — it
 records the change, it does not apply it.

package/assets/.appweaver/orchestrator/rev-templates/design-template.skeleton.md

@@ -30,13 +30,13 @@
     • Exactly one §2 subsection's heading contains the word "Integration".
       `aw-xref` matches it by keyword to extract contract edges, which is what
       lets a derived layout and the greenfield layout be read by one tool.
-    • Each published endpoint is a `####` ENDPOINT BLOCK — the heading
-      `#### `[VERB] [/route]`` and its **Operation id** field — with the
-      "Requests from the frontend lane" table after the blocks, inside whichever
-      §2 axis publishes them. The contract scripts read exactly this form:
-      `contract-draft` drafts api-draft.json from the headings, and
-      `contract-requests` reads the operation ids and the table. The axis keeps
-      the project's own name; only the block form is fixed.
+    • The published endpoints are NOT in this template. Each feature keeps them
+      in its api-plan.md, from the kit's api-plan-template — one form for every
+      project, because the contract scripts read it (`contract-draft` drafts
+      api-draft.json from it, `contract-requests` reads its operation ids and
+      requests table, `contract-merge` merges a change into it). The §2 axis
+      that publishes them keeps the project's own name and its component table,
+      and ends with the one line pointing to api-plan.md.
     • The traceability spine (§4) and both ledgers (§5 DA-n, §6 WA-n) survive
       every layout — the analyze gates read them.
     • The §0–§6 numbering itself: `plan`'s bootstrap_bf branch names those
@@ -69,6 +69,8 @@
 
 **Source model**: `specs/[Context]/domain-model.md`   <!-- where the context has one -->
 
+**API plan**: `specs/[Context]/[Feature]/api-plan.md`   <!-- the endpoints this service publishes, which §2 realises -->
+
 **Version**: v1.0
 
 **Status**: Draft
@@ -176,8 +178,9 @@
      the titles are the code's answer — the slots below are illustrative
      positions, not a required set. In each: the components that live there,
      their behaviour in signature form, and the contracts they expose or
-     require. The endpoints the service PUBLISHES take the endpoint block form
-     shown in the axis below. -->
+     require. The endpoints the service PUBLISHES are in the feature's
+     api-plan.md; the axis below that publishes them ends with the line
+     pointing there. -->
 
 ### 2.1 [PROJECT_STRUCTURAL_AXIS_NAME]
 
@@ -194,47 +197,18 @@
 
 ### 2.[M] [AXIS_THAT_PUBLISHES_THE_ENDPOINTS]
 
-<!-- PINNED FORM, in whichever axis this project publishes its endpoints from. The
-     axis keeps the project's own name and its component table; what is fixed is
-     each endpoint's block below it and the requests table after the blocks,
-     because the contract scripts read exactly these: the `#### `VERB /route``
-     heading (contract-draft writes api-draft.json from it), the **Operation id**
-     field (the id the service serves, which the frontend plan binds to) and the
-     `| Request | Outcome |` table (contract-requests). A project that publishes no
-     endpoint omits both. -->
+<!-- The axis this project publishes its endpoints from keeps the project's own
+     name and its component table. The endpoints themselves — route, verb,
+     operation id, shapes, the error contract — and the answers to the frontend
+     lane's requests are in the feature's api-plan.md, in the kit's fixed form the
+     contract scripts read, and each maps to a component here. End the axis with
+     the line below; a project that publishes no endpoint omits it. -->
 
 | Component | Behaviour (signature) | Pre / Post / Raises | Serves |
 |---|---|---|---|
 | `[Component]` | `[operation](args) -> result` | [pre / post / raises] | FR-00X · US-Y |
 
-#### `[VERB] [/route]` — [purpose] · Serves US-Y · FR-00X
-
-- **Operation id**: `[OperationId]`  <!-- the endpoint's name in the published API document. An endpoint the code already serves keeps the id it publishes, spelled exactly as the code spells it; where it publishes none, write `—` and record a §5 DA-n saying so — never an invented id, which the service's exported document would not carry. A NEW endpoint takes an id unique across the service, and implement gives it exactly that. -->
-- **Auth**: [required role/scope, as enforced]
-- **Request**: `[path/query params]` + body `{ [field]: [type], … }`
-- **Success**: `2xx` → `{ [response shape] }`
-- **Errors** *(the error contract)*:
-
-  | Status | When | Body shape |
-  |---|---|---|
-  | [status] | [when it is returned] | [body shape] |
-
-- **Maps to**: `[Component]` (§2.n)
-
-#### Requests from the frontend lane
-
-<!-- THE ANSWERS to the frontend plan's "Contract deltas needed" table, one row
-     per RQ-n it raises. PUBLISH: add the endpoint above — under the proposed
-     operation id unless it clashes with one this service already uses — and name
-     the id here. DECLINE: say why in one line; a request the spec does not
-     support is declined as a spec gap for `specify`, never published on a guess.
-     Keep every answered row; write `None` instead of the table when the frontend
-     plan raises no request — always so for a plan reversed from code, whose
-     frontend binds only to what the service already serves. -->
-
-| Request | Outcome | Operation id | Why |
-|---|---|---|---|
-| RQ-[n] | published / declined | `[OperationId]` / — | [one line — required when declined] |
+The endpoints this service publishes — route, verb, operation id, request, success and errors — and its answers to the frontend lane's requests are in [api-plan.md](api-plan.md), the API contract the frontend lane binds to.
 
 ### 2.[N] External Integrations
 
@@ -302,9 +276,9 @@
 ## Change History
 
 <!-- A row is appended when this plan is RE-DERIVED to carry a change: the plan
-     is derived from spec.md and the context's domain-model.md, and finalize-delta
-     merges a change into those two, never into this one (`plan main` re-derives
-     it). close-delta bumps the version and stamps it into the header, so a header
+     is derived from spec.md, the context's domain-model.md and api-plan.md, and
+     finalize-delta merges a change into those three, never into this one (`plan
+     main` re-derives it). close-delta bumps the version and stamps it into the header, so a header
      ahead of the newest row means the plan has not been re-derived since. A
      change is planned as a DELTA in the change's own directory, never as a new
      plan document. Newest last. -->

package/assets/.appweaver/orchestrator/rev-templates/ui-delta-design-template.skeleton.md

@@ -47,7 +47,7 @@
 
 **Delta spec**: `changes/[CR-ID]/delta-spec.md`
 
-**Service delta**: [`changes/[CR-ID]/delta-backend-plan.md`, or `None — experience-only change`]
+**API delta**: [`changes/[CR-ID]/delta-api-plan.md`, or `None — the change leaves the API unchanged`]
 
 <!--
   This delta applies to the SINGLE master plan at
@@ -82,7 +82,7 @@ it serves.]
      "Section" names a section of THIS project's master frontend plan — the same
      section titles the generated frontend plan template carries. A binding row's
      element LEADS with the operation id the service names the endpoint by — implement
-     checks it against the exported API document. -->
+     checks it against the API document combined from the API plans' drafts. -->
 
 | Section (§ in frontend-plan.md) | Element | Kind | Serves |
 |---|---|---|---|
@@ -115,8 +115,9 @@ it serves.]
 ## Contract impact
 
 [What this change needs from the service lane, bound against its published surface —
-the delta-spec's IC- ids and the service delta's "Contract deltas for the frontend
-lane" table: bindings added, changed or no longer used. Anything the experience
+the delta-spec's IC- ids and the change's API delta (delta-api-plan.md) — its Contract
+deltas table and endpoint blocks — and, for an endpoint the change leaves alone, the
+feature's api-plan.md: bindings added, changed or no longer used. Anything the experience
 requires that the contract does not offer is raised back to the service lane —
 never worked around in the client. Or `None`.]
 
@@ -150,8 +151,9 @@ shared state container or a navigation edge changed.]
 ## On merge
 
 `finalize-delta` merges the change's SPEC half into `spec.md` and its MODEL half into the
-context's `domain-model.md`, in one transaction, and leaves the change OPEN. It does NOT
-merge this document: the master plan is derived from those two, so `plan main` re-derives
-it rather than patching it. `close-delta` archives this file with the change and bumps the
+context's `domain-model.md`, in one transaction, merges its `delta-api-plan.md` into the
+feature's `api-plan.md` by script, and leaves the change OPEN. It does NOT merge this
+document: the master plan is derived from those three, so `plan main` re-derives it rather
+than patching it. `close-delta` archives this file with the change and bumps the
 ONE version both lanes share. None of it is this document's job — it records the change,
 it does not apply it.

package/assets/.appweaver/orchestrator/rev-templates/ui-design-template.skeleton.md

@@ -40,7 +40,7 @@
 
   §5 IS THE LANE BOUNDARY. Contract binding is the only place the service lane
   enters: the frontend plan reads the WHOLE spec but only the service's
-  PUBLISHED SURFACE — the spec's IC- ids and the API contracts backend-plan.md
+  PUBLISHED SURFACE — the spec's IC- ids and the endpoints api-plan.md
   states. (⌛ `plan` will emit that surface as a design-contract.md projection;
   the rule does not change when it does, only what §5 reads.) The requirement
   is shared and must not fork; the implementation is not shared and must not
@@ -92,7 +92,7 @@
     the aggregate's structure. This lane consumes the published surface at §5, not
     the domain, so the model is not in its context.)
   - THE PUBLISHED SURFACE IS THE ONLY SERVICE INPUT (§5) — the spec's IC- ids and
-    the API contracts backend-plan.md states, never the service's internals.
+    the endpoints api-plan.md states, never the service's internals.
 
   STRUCTURE FOLLOWS THIS LANE'S CODE
   - [GENERATED_LANE_STRUCTURE_NOTE] — form: one or two sentences naming the
@@ -219,11 +219,11 @@ does none.]
 
 <!-- THE LANE BOUNDARY. One row per service operation this feature's UI depends
      on, bound against the service's PUBLISHED SURFACE — the spec's IC- ids and
-     the API contracts backend-plan.md states — never its internals: no table,
+     the endpoints api-plan.md states — never its internals: no table,
      handler or persistence assumption crosses this line. Where the surface does
      not name an operation yet, bind against the spec's own IC-/FR- surface and
      record that as a §8 assumption. The OPERATION ID is the endpoint's name in the
-     service's published API document (as backend-plan.md records it) — implement
+     service's published API document (as api-plan.md records it) — implement
      finds the endpoint by it; `—` where none is named yet. -->
 
 | Screen / component | Operation id | Operation (from the contract) | Sends (field shape) | Receives (field shape) | Failure handling | Serves |
@@ -234,7 +234,7 @@ does none.]
 
 <!-- THE REQUEST LEDGER. One row per operation the experience needs that the
      contract does not offer — raised back to the service lane, never worked
-     around in the client. Each request keeps its RQ-n for life. The backend plan
+     around in the client. Each request keeps its RQ-n for life. The API plan
      answers in its "Requests from the frontend lane" table, published under an
      operation id or declined with the reason; an answered request is re-bound
      above to that id. Write `None` instead of the table when there is none. -->