aw-spec-cli 0.1.32 → 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.4.0
+version: 2.6.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
@@ -191,7 +191,7 @@ standards:
 vars:
   # The provenance stamp every generated file carries. It names THIS workflow's version,
   # so it moves with `version:` above — one value, never a literal repeated per prompt.
-  generated_by:   "aw-spec-onboard/2.4.0"
+  generated_by:   "aw-spec-onboard/2.5.0"
   bundle_present: "false"   # set by the scan (the bundle holds concepts); reported, gates nothing
   conformant:     "false"   # OKF conformance-gate driver
   pack_present:   "false"   # the project tier exists ⇒ repo_gov, so this context AMENDS it
@@ -332,11 +332,13 @@ workflow:
       - { name: bundle_dir,       from: "$.bundle_dir" }
       - { name: bundle_present,   from: "$.bundle_present" }
       - { name: bundle_md_count,  from: "$.bundle_md_count" }
-      # The frontend lane, as the CODE evidences it. `frontend_present` is true only
+      # The frontend lane, as the CODE evidences it. `frontend_evidenced` is true only
       # where a candidate root reached lane strength (a frontend build config, or a
       # real set of component/view files) — loose scripts and stylesheets under a
-      # wwwroot/ are reported in the substrate but are NOT a lane.
-      - { name: frontend_present,   from: "$.frontend_present" }
+      # wwwroot/ are reported in the substrate but are NOT a lane. It is the code's
+      # answer, kept apart from `frontend_present` (the UI rule tier exists, from
+      # pack_setup); which lanes this run governs is the declaration's answer, ui_lane.
+      - { name: frontend_evidenced, from: "$.frontend_present" }
       - { name: frontend_separable, from: "$.frontend_separable" }
       - { name: frontend_roots,     from: "$.frontend_roots" }
       - { name: frontend_root_count, from: "$.frontend_root_count" }
@@ -2303,6 +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 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.
@@ -2361,9 +2370,14 @@ workflow:
       the generated master template. Never name a layering — neither one you know nor one the
       master did not derive.
       - CARRY OVER the neutral parts of rev-templates/delta-design-template.skeleton.md (in
-        context): Change summary, 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. Keep behaviour technology-agnostic (signatures +
+        context): Change summary, Model changes this plan realises, Depends on, Cross-section
+        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
@@ -2560,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
@@ -2614,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.