aw-spec-cli 0.1.33 → 0.1.34

package/assets/.appweaver/orchestrator/workflows/aw-spec-onboard.orch.yaml

@@ -152,7 +152,7 @@
 
 name: aw-spec-onboard
 description: Onboard an existing codebase for brownfield DEVELOPMENT — a deterministic whole-repo scan produces a high-level OKF feature map (folders/concepts) PLUS the project-level governance scaffold (split constitution + guardrails/brf-<domain>/ with its DOMAIN rule files at domain/ + domain-rule-bindings + code-derived TECHNICAL rule files at service/ + tech-rule-bindings + activated domain), all provisional-from-scan. The first context authors that tier; every later context amends it additively from its own code (new rules, principles and map entries — never a rewrite, renumbering or deletion; a contradiction is recorded as a Divergence note), and a tier that does not exist yet, such as a lane declared after an earlier onboard, is authored in full. Naming an already-onboarded context re-runs that governance pass alone. Where the scan finds a frontend lane in the CODE, it also authors that lane's half — constitution.ui.md (UX-*) — and its code-derived rule files at brf-<domain>/frontend/, mapped under `## /aw-spec-ui-constitution`, `## /aw-spec-plan-frontend` and `## /aw-spec-implement-frontend`; a backend-only repo gets none of it. Every rule tier is reverse-engineered from the CODE alone (never a greenfield rule file), evidenced-only, and WIRED per-workflow so the whole forward pipeline AND adopt govern against THIS codebase — never a greenfield fallback. It also reverse-engineers the repo's own technical structure into a project-specific design + delta-design template pair, installed as the project template overrides, and — where the lane exists — the frontend lane's own pair from the UI source. Every authoring step is shaped by a NEUTRAL rev-templates skeleton; no greenfield constitution, rule file or document template is ever placed in context. Accepts an optional concerns list to look for (onboard decides which are actually present). Reads any declared lane whose folder exists, never writes one; a lane declared before it is built is governed as absent and its governance left to the developer. No migration content; never modifies source.
-version: 2.5.0
+version: 2.6.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
@@ -2305,16 +2305,13 @@ workflow:
         signature form + the ports/contracts. Keep exactly one subsection whose heading
         contains the word "Integration" (the External Integrations table — one port/adapter row
         per IC-): aw-xref matches it by keyword, so it is pinned regardless of layout.
-      - THE PUBLISHED SURFACE IS A PINNED FORM. In the §2 axis this project publishes its
-        endpoints from (titled with the project's own name for it), keep the skeleton's
-        endpoint block exactly — the heading `#### `[VERB] [/route]` — [purpose] · Serves …`,
-        then **Operation id**, Auth, Request, Success, the Errors table and Maps to — and the
-        `#### Requests from the frontend lane` table after the blocks. The contract scripts
-        read exactly this form: the API draft is written from the headings and the request
-        ledger between the lanes reads the operation ids and the table, so endpoints listed
-        in a table instead leave both empty. Keep the Operation id comment: an endpoint the
-        code already serves keeps the id it publishes, `—` with a §5 DA-n where it publishes
-        none, never an invented one. Omit both only where the code publishes no endpoint.
+      - THE PUBLISHED ENDPOINTS ARE NOT IN THIS TEMPLATE. Each feature keeps them in its own
+        api-plan.md, from the kit's api-plan-template, whose endpoint block form is the same
+        in every project because the contract scripts read exactly it. In the §2 axis this
+        project publishes its endpoints from (titled with the project's own name for it),
+        keep its component table and end it with the skeleton's line pointing to
+        api-plan.md; write no endpoint block and no requests table. Omit the line only where
+        the code publishes no endpoint.
       - §3 Cross-Cutting Concerns — one row per concern THIS project's governance carries, read
         from the technical constitution (Serves = a spec id or a §5 DA-n). Do not import a
         standard concern list the constitution does not evidence.
@@ -2374,13 +2371,13 @@ workflow:
       master did not derive.
       - CARRY OVER the neutral parts of rev-templates/delta-design-template.skeleton.md (in
         context): Change summary, Model changes this plan realises, Depends on, Cross-section
-        impact, Contract deltas for the frontend lane, Other open deltas, Regression targets,
-        New assumptions/deviations (DA-n / WA-n), On merge — word for word: finalize-delta
-        merges the spec and the model, never this plan, which `plan main` re-derives. Keep
-        the contract table's Operation id and Change columns and its added / changed /
-        removed values: analyze-plan-delta reads them to warn when a change alters or
-        removes an operation the frontend binds to. Omit that section only where the code
-        has no frontend lane. Keep behaviour technology-agnostic (signatures +
+        impact, API changes, Other open deltas, Regression targets, New
+        assumptions/deviations (DA-n / WA-n), On merge — word for word: finalize-delta
+        merges the spec, the model and the change's delta API plan, never this plan, which
+        `plan main` re-derives. API changes is the one line pointing to delta-api-plan.md:
+        a change's endpoints are planned there, from the kit's delta-api-plan-template,
+        never in this template — omit the section only where the code publishes no
+        endpoint. Keep behaviour technology-agnostic (signatures +
         contracts, no code); a shared element is MODIFIED in place, never duplicated; every
         changed element serves a spec id.
       - This aligns with the delta-plan module, which classifies "per the master's OWN
@@ -2577,8 +2574,9 @@ workflow:
         most UI defects live. Where the code handles no error or empty state, template the
         section so the downstream author must record that as-built — never delete it.
       - §5 Contract Binding — keep the lane boundary intact: the binding table binds
-        against the service's PUBLISHED SURFACE (the spec's IC- ids and the API contracts
-        backend-plan.md states), never the service's internals. Note in the authoring
+        against the service's PUBLISHED SURFACE (the spec's IC- ids and the endpoints the
+        feature's api-plan.md states, each by its operation id), never the service's
+        internals — the backend plan is not this lane's to read. Note in the authoring
         comment that where the surface does not name an operation yet, the author binds
         against the spec's own IC-/FR- surface and logs a §8 assumption.
       - §7 Traceability, §8 Assumptions (DA-n), §9 Deviations (WA-n), Change History — carry
@@ -2631,8 +2629,9 @@ workflow:
       - CARRY OVER the neutral parts of rev-templates/ui-delta-design-template.skeleton.md
         (in context): Change summary, Interaction states touched, Contract impact,
         Cross-section impact, Regression targets, New assumptions/deviations (DA-n / WA-n),
-        On merge — word for word: finalize-delta merges the spec and the model, never this
-        plan, which `plan main` re-derives.
+        On merge — word for word: finalize-delta merges the spec, the model and the change's
+        delta API plan, never this plan, which `plan main` re-derives. Contract impact cites
+        the change's API delta (delta-api-plan.md), never the delta backend plan.
       - KEEP the "Interaction states touched" section whatever this lane's code shows: a new
         interaction that ships without its loading, empty, error and permission-denied states
         is an incomplete delta, and the template is where that is enforced.