aw-spec-cli 0.1.8 → 0.1.10

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

@@ -0,0 +1,1822 @@
+# =============================================================================
+# aw-spec-onboard (orchestrator) — the entry step of the Brownfield DEVELOPMENT flow
+#
+# Onboard an EXISTING codebase into aw-spec so it can be DEVELOPED (evolved, not
+# migrated) governed exactly like greenfield and as lightly as OpenSpec. Runs ONCE
+# per repo, over the WHOLE codebase (project-level, not per-slice). It does two
+# things, both from a single deterministic whole-repo scan — no slice is adopted yet:
+#
+#   1. FEATURE MAP — a HIGH-LEVEL OKF discovery index of the features/aggregates the
+#      code contains (folders/concepts + a bounded-context map + the tech stack). It
+#      is a shallow map to pick from, NOT a deep reverse — the deep per-feature
+#      reverse (spec.md + design.md) is /appweaver adopt, done just-in-time when
+#      you are about to develop that feature.
+#
+#   2. GOVERNANCE SCAFFOLD — the PROJECT-level governing tier, established once from
+#      the whole-repo vantage so forward development is consistent from the first
+#      change: the split constitution (technical + domain), the guardrails/projects/
+#      brf-<domain>/domain/ rule-file set (+ domain-rule-bindings), the domain charter
+#      that set is headed by, and the activated domain. Because nothing is adopted yet, this tier is
+#      a PROVISIONAL scaffold evidenced by the SCAN (project identity + bounded-context
+#      map are firm; principles/rules are marked provisional). adopt then RECONCILES
+#      each with the slice's own evidence (BR-/CN-/DC-/IC- ids) when that feature is
+#      developed — the "created here, updated when taking each slice" contract.
+#
+#   ONBOARD  →  adopt <Feature> (JIT)  →  specify → design → analyze-delta-design → implement-delta → build → finalize-delta → analyze-slice → close-delta   ← you are here
+#
+# Establishing the PROJECT-scoped constitution here (whole-repo vantage) — not from a
+# single adopted slice — is deliberate: it keeps governance project-scoped from day
+# one and stops a first-adopted feature from biasing it (adopt only ADDS evidence).
+#
+# This is the DEVELOPMENT flow — there is NO migration content: no migration backlog,
+# no seams/adopt-order, no strangler, no parity, no cutover. Modernization/migration
+# is a separate, later phase. Reuses proven machinery unchanged (the scan, the
+# constitution scripts, the neutral rev-templates skeletons); the new agent PROMPTS read
+# the SCAN + representative SOURCE, not adopted docs. 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), so forward development follows the
+# as-built architecture, not the greenfield four-layer layout.
+#
+# ONE ORACLE — THE CODE. Every artifact this workflow writes is evidenced from source, and
+# the discipline is structural rather than instructional: no greenfield constitution, rule
+# file or document template is ever placed in a step's context. Where a shape reference is
+# needed, the step reads a NEUTRAL SKELETON from rev-templates/ that carries the format and
+# deliberately carries no principle set, no rule, no layering and no technology. That is
+# why "do not copy the exemplar" never has to be trusted — there is no exemplar present.
+#
+# CODE-DERIVED RULE SETS + MAPS (both tiers): onboard authors, from the code ALONE
+# (never a greenfield rule file), BOTH the DOMAIN rule-file set
+# (guardrails/projects/brf-<domain>/domain/*.domain.md +
+# domain-rule-bindings.md) AND the TECHNICAL rule-file set (guardrails/projects/brf-<domain>/service/*.md
+# + tech-rule-bindings.md), then WIRES each per-workflow. This is what makes the WHOLE
+# forward pipeline AND adopt govern against THIS codebase's rules — resolve-domain /
+# resolve-tech read the activated brf-<domain>'s maps, so no workflow ever falls back to a
+# rule file from another project. Both sets are evidenced-only (a rule
+# is written only for a concern the code exhibits) and may be seeded with an optional list
+# of concerns to look for (onboard still DECIDES presence + implementation from the code).
+# The technical set carries ONE file for /specify — service/domain-modelling.md, the AS-BUILT
+# modelling METHODOLOGY (how this code expresses a domain model: what marks an aggregate
+# root, entity vs value object, where invariants live, the context boundary). It is the
+# code-derived analog of the greenfield corpus's technology/<stack>/domain-driven-design.md, and the only
+# thing this tier is ever allowed to put under `## /aw-spec-specify`. WHAT the model is
+# stays in the domain set (its domain-model file); HOW to model lives here.
+#
+# THE FRONTEND LANE (only where the CODE has one). A repo with a user interface gets the
+# lane's governance reverse-engineered on the same terms as the other two tiers — from the
+# code and nothing else:
+#   .appweaver/memory/constitution.ui.md          — the lane's UX-* base, authored from the UI
+#       source (never from a greenfield UI template's content), then linted like the other
+#       halves and composed in. Parallel to the technical base, so its numbering is its own.
+#   guardrails/projects/brf-<domain>/frontend/*.md — the code-derived lane rule set, the detail
+#       layer under those UX-* principles, plus `## /aw-spec-ui-constitution` appended to
+#       tech-rule-bindings.md so a later /appweaver constitution re-ratifies from THIS
+#       project's lane rules.
+#   .appweaver/templates/overrides/ui-design-template.md + ui-delta-design-template.md — the
+#       lane's own document pair, reverse-engineered from the UI source the same way the
+#       service pair is reverse-engineered from the service code. The lane is governed by a
+#       different constitution half and implemented by different commands, so it gets its own
+#       design document rather than a section inside the service design; the only thing that
+#       crosses between them is the design contract. Their consumers (⌛ ui-design,
+#       ui-implement) are not built yet — the templates are written now because the
+#       whole-repo evidence for them exists exactly once, at onboard.
+# RUN /appweaver select-stack FIRST. It is the first command of the brownfield
+# sequence and this workflow REFUSES to run without it, because it needs to be told three
+# things before it can start: which lanes this project has, where each lane's source is,
+# and what each lane's stack is. Those decide which constitution halves and rule sets get
+# generated, which subtrees are scanned, and what technology the derived rules name.
+# select-stack detects all three from the repo's own files and proposes them, so answering
+# it on an existing codebase is mostly confirmation — but it is a person's confirmation,
+# which is exactly what detection on a legacy repo needs. A declared source path that is
+# not a directory stops this run with the fix named rather than producing a scaffold
+# reverse-engineered from nothing.
+#
+# WHICH LANES EXIST is therefore the DECLARATION's answer, and it answers in both
+# directions — a project that declared `(none)` for the UI lane gets no UI half, no
+# frontend rule files and no `## /aw-spec-ui-*` mapping, and one that declared `(none)`
+# for the service lane gets no technical half and no service rules. The deterministic
+# scan is still what reads the code, now pointed AT the declared subtree: it decides what
+# the governance SAYS, and the declaration decides what there is to govern. A declared
+# lane whose source path holds nothing recognisable is reported, because the governance
+# derived from it will be thin.
+#
+# ONE ORACLE, UNCHANGED. Nothing about where the CONTENT comes from has moved. Every
+# constitution half, rule file and design template below is derived from this repository's
+# own source plus a NEUTRAL skeleton, with no greenfield corpus, filled constitution or
+# kit template in context. The declaration selects the subtree; it supplies no governance.
+#
+# THIS WORKFLOW NEVER WRITES .appweaver/stacks.json. It used to, back when a repo could
+# reach onboard undeclared: it ran its own detection pass, recorded what it found marked
+# `origin: reverse-engineered`, and was gated never to overwrite a lane a person had
+# confirmed. With the declaration required at the top, that gate can never open and the
+# pass was re-deriving an answer the run already had. `lane-declare` has one caller again
+# — select-stack — and this workflow only reads.
+#
+# Never modifies source — every write lands in the OKF bundle, the specs governance dir,
+# guardrails/projects/ (domain/ + service/ + frontend/ rule sets + both maps), or the
+# .appweaver/templates/overrides/ design templates.
+#
+# Launch:  /appweaver onboard [domain-name / scope hint] [; concerns: a, b, c]
+#   e.g.   /appweaver onboard Pharma
+#   e.g.   /appweaver onboard "Pharma; concerns: auditing, concurrency, authorization"
+# =============================================================================
+
+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/projects/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 and refined per slice by adopt. 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`; 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, never writes one. No migration content; never modifies source.
+version: 1.6.0
+agent_agnostic: true
+dialect: aw-spec.orchestrator/v1
+
+inputs:
+  user_input:
+    description: >-
+      Optional free-text hint. May carry (a) a domain name for the governance project
+      (e.g. Pharma → guardrails/projects/brf-pharma/); (b) a scope/focus hint for the
+      feature map; and/or (c) a CONCERNS LIST to look for, as a "concerns: a, b, c"
+      clause (e.g. "Pharma; concerns: auditing, concurrency, authorization"). The
+      concerns are a SEARCH HINT only — both rule-set authors still DECIDE which
+      concerns are actually present from the code, and are never limited to the list.
+      When omitted, the domain defaults to the PROJECT name from the OKF overview,
+      then the repo basename; concerns are auto-discovered from the code.
+    required: false
+    bind: USER_INPUT
+
+scripts:
+  inventory:
+    sh:  .appweaver/scripts/bash/aw-inventory.sh
+    ps1: .appweaver/scripts/powershell/aw-inventory.ps1
+  revcon:
+    sh:  .appweaver/scripts/bash/aw-rev-constitution.sh
+    ps1: .appweaver/scripts/powershell/aw-rev-constitution.ps1
+  actions:
+    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
+    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
+
+# The sticky set carries the kit's universal operating rules and NOTHING project-shaped.
+# agent_generate ALWAYS injects the standards set (it cannot opt out), so keeping it to
+# behaviour-only guarantees no governance skeleton or exemplar from another project leaks
+# into the feature-map agent. Every step is fed EXACTLY what it needs via build_context;
+# the technical-half author gets its neutral shape skeleton through context, not here.
+standards:
+  - { path: .appweaver/ai-rules.md }   # kit-resident: the universal operating rules, every flow
+
+vars:
+  bundle_present: "false"   # inventory bundle_guard driver
+  conformant:     "false"   # OKF conformance-gate driver
+  pack_present:   "false"   # project anti-clobber driver
+  technical_ok:   "false"   # technical-half lint guard
+  domain_ok:      "false"   # domain-half lint guard
+  ui_ok:          "false"   # UI-half lint guard
+  ui_lane:        "false"   # set from the DECLARATION below; gates the whole frontend block
+  svc_lane:       "false"   # set from the DECLARATION below; gates the whole service block
+
+workflow:
+
+  # ═══════════════════ PART 1 — FEATURE MAP (high-level discovery) ═════════════
+  # A deterministic scan + one enrichment agent, mirroring inventory's shape but
+  # producing a SHALLOW discovery index (drop the migration backlog / seams /
+  # adopt-order — this is development, not migration).
+
+  # 0. WHICH LANES, AND WHERE IS THEIR SOURCE. select-stack is the first command of
+  #    the brownfield sequence, and this is why: onboard reverse-engineers governance
+  #    OUT of a subtree, so it has to be told which subtree before it starts. The
+  #    declaration answers three questions at once — which lanes exist (so which
+  #    constitution halves and rule sets to generate), where each lane's source is (so
+  #    what to scan), and what each lane's stack is (so the derived rules name the
+  #    right technology).
+  #
+  #    The on-disk check is ON here, unlike in constitution: this run is about to READ
+  #    those directories. A declared path that is not there stops the run with the fix
+  #    named, rather than producing a governance scaffold reverse-engineered from
+  #    nothing.
+  - id: lane_model
+    action: execute_script
+    script: { ref: actions }
+    subcommand: lane-verify
+    args: ["--command", "/appweaver onboard"]
+    outputs:
+      - { name: lane_model_ok,     from: "$.ok" }
+      - { name: lane_model_issues, from: "$.message" }
+      - { name: lane_kinds,        from: "$.kinds" }
+      - { name: be_declared,       from: "$.backend_declared" }
+      - { name: be_lane_id,        from: "$.backend_lane_id" }
+      - { name: be_profile,        from: "$.backend_profile" }
+      - { name: be_root,           from: "$.backend_source_path" }
+      - { name: fe_declared,       from: "$.frontend_declared" }
+      - { name: fe_lane_id,        from: "$.frontend_lane_id" }
+      - { name: fe_profile,        from: "$.frontend_profile" }
+      - { name: fe_root,           from: "$.frontend_source_path" }
+
+  - id: lane_model_gate
+    action: verify_context
+    require_true: lane_model_ok
+    on_false: stop
+    on_false_message: >
+      /appweaver onboard cannot run: {{lane_model_issues}}
+      onboard reverse-engineers this repository's governance out of its source, so it
+      has to be told which subtrees hold which lane before it starts scanning. Run
+      /appweaver select-stack first — it detects what this repo already is, proposes
+      the stack and the source path for each lane, and lets you correct both.
+
+  - id: lane_kinds_gate
+    action: verify_context
+    require_non_empty: lane_kinds
+    on_empty: stop
+    on_empty_message: >
+      No lane is declared — .appweaver/stacks.json exists but declares neither a service
+      nor a UI lane, so onboard has no source to reverse-engineer. Re-run
+      /appweaver select-stack and declare at least one lane.
+
+  # 1. DETERMINISTIC scan of the current codebase → JSON substrate (files, churn,
+  #    categories, aggregate_signals = candidate feature roots), and reports whether
+  #    a bundle already holds curation.
+  #
+  #    SCOPED BY THE DECLARATION. Backend signals come from outside the UI lane's
+  #    subtree (and inside the service lane's); frontend signals come from the UI
+  #    lane's subtree alone. This substrate is inlined verbatim into every agent
+  #    request this run makes, so an unscoped scan puts the whole frontend file list in
+  #    front of the step deriving the SERVICE rules and every backend aggregate in front
+  #    of the steps deriving the UI's — while each prompt tells the model to ignore what
+  #    it has just been handed. Scoping removes the material instead of arguing with it,
+  #    and shrinks six payloads at the same time.
+  - id: scan
+    action: execute_script
+    script: { ref: inventory }
+    subcommand: scan
+    args: ["--service-root", "{{be_root}}", "--ui-root", "{{fe_root}}"]
+    outputs:
+      - { name: inventory_json,   from: "$.inventory_json" }
+      - { name: root,             from: "$.root" }
+      - { name: head,             from: "$.head" }
+      - { name: file_count,       from: "$.file_count" }
+      - { name: aggregate_count,  from: "$.aggregate_count" }
+      - { 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
+      # 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" }
+      - { name: frontend_separable, from: "$.frontend_separable" }
+      - { name: frontend_roots,     from: "$.frontend_roots" }
+      - { name: frontend_root_count, from: "$.frontend_root_count" }
+      # The PRIMARY root / kind / stack — the single values the lane declaration needs.
+      - { name: frontend_root,      from: "$.frontend_root" }
+      - { name: frontend_kind,      from: "$.frontend_kind" }
+      - { name: frontend_stack,     from: "$.frontend_stack" }
+      # Did the DECLARED UI subtree actually contain UI? A declared lane is a lane
+      # either way — this is what separates governance reverse-engineered from real
+      # source from governance derived from an empty directory.
+      - { name: ui_evidence_found,   from: "$.ui_evidence_found" }
+      - { name: backend_file_count,  from: "$.backend_file_count" }
+      - { name: frontend_file_count, from: "$.frontend_file_count" }
+      - { name: scoped_service_root, from: "$.declared_service_root" }
+      - { name: scoped_ui_root,      from: "$.declared_ui_root" }
+
+  # 1b. Substance gate: no candidate features → nothing to map.
+  - id: require_aggregates
+    action: verify_context
+    require_true: aggregate_count
+    on_false: stop
+    on_false_message: "Scan found no candidate features in {{root}} (file_count={{file_count}}). Point /appweaver onboard at a codebase with a recognizable domain/vertical-slice layout, or scan a subtree that contains one."
+
+  # 1c. Curation guard (OKF rule): a bundle that already has concept files is
+  #     curation — regenerating from scratch would destroy it.
+  - id: bundle_guard
+    action: verify_context
+    require_value: bundle_present
+    equals: "false"
+    on_mismatch: stop
+    on_mismatch_message: "The OKF feature-map bundle at {{bundle_dir}} already holds {{bundle_md_count}} concept file(s) — onboard would overwrite that curation. Back up or remove {{bundle_dir}} to re-onboard from scratch."
+
+  # 1d. FRONTEND LANE — the DECLARATION decides that it exists, and the CODE decides
+  #     what its governance says. Those are two different questions and they used to be
+  #     answered by one signal.
+  #
+  #     Before, the scan's own strength test (a frontend build config, or UI_STRONG_MIN
+  #     component files) both found the lane and supplied its evidence. That test exists
+  #     to stop a scan INVENTING a lane out of a wwwroot/ of loose scripts, which is the
+  #     right instinct and the wrong authority: it also meant a real lane the heuristic
+  #     scored one file short simply did not exist, and no amount of declaring it helped.
+  #     Now the project says which lanes it has and where their source is, and the scan
+  #     — pointed at that subtree — says what is in there.
+  #
+  #     ONE ORACLE, UNCHANGED. Nothing about where the CONTENT comes from has moved:
+  #     every rule, principle and template below is still derived from this repository's
+  #     own source and from a neutral skeleton, with no greenfield corpus in context.
+  #     The declaration selects the subtree; it never supplies a word of the governance.
+  # No service lane ⇒ the technical lint loop has nothing to check, so its guard is
+  # satisfied rather than left at its "not yet verified" default; a declared lane
+  # restores it, because that half does get authored and does get linted.
+  - id: svc_lane_absent
+    action: set
+    vars: { svc_lane: "false", technical_ok: "true", setup_tech_flag: "--no-technical" }
+  - id: svc_lane_declared
+    action: set
+    condition: "{{be_declared}}"
+    vars: { svc_lane: "true", technical_ok: "false", setup_tech_flag: "" }
+
+  # A repo with no service lane. Rare in brownfield and real — a static site, a
+  # component library, a front end whose API lives in another repository. The
+  # technical half, the service rule set and the service design templates are all the
+  # SERVICE lane's, so none of them is authored, and saying so is better than leaving
+  # someone to notice that guardrails/projects/<p>/service/ is empty.
+  - id: svc_lane_warning
+    action: verify_context
+    require_true: svc_lane
+    on_false: continue
+    on_false_message: >
+      No service lane in .appweaver/stacks.json — skipping the TECHNICAL constitution
+      half, the service rule set (the project's own service/ folder) and the
+      service design/delta-design template overrides. All three are the service lane's,
+      and this project declared it has none. The domain rule set, the domain half and —
+      where a UI lane is declared — the whole frontend tier are authored as usual. If
+      this repo does have backend source, run /appweaver select-stack, declare it and
+      re-run onboard.
+
+  - id: ui_lane_absent
+    action: set
+    vars:
+      ui_lane: "false"
+      ui_evidence: ""
+      ui_declaration_note: "no frontend lane is declared in .appweaver/stacks.json — this repo is governed as backend-only"
+  - id: ui_lane_declared
+    action: set
+    condition: "{{fe_declared}}"
+    vars:
+      ui_lane: "true"
+      ui_evidence: "lane '{{fe_lane_id}}' ({{fe_profile}}) is declared at the source path {{fe_root}}; the scan found UI source there — {{frontend_roots}}"
+      ui_declaration_note: "lane '{{fe_lane_id}}' ({{fe_profile}}) at {{fe_root}} — the declared source path this run reverse-engineered the UI governance out of"
+
+  # A declared UI lane whose source path holds nothing a scan recognises as UI. The
+  # path exists — lane-verify already refused the run otherwise — so this is not a
+  # broken declaration, it is an empty one: a lane scaffolded but not yet built, or a
+  # source path one directory too high. Announce and continue rather than stop: the
+  # declaration is a person's statement and is left exactly as it stands, but the UI
+  # governance below will be thin, and it is better to say why now than to let someone
+  # discover a UX base derived from an empty directory.
+  - id: ui_evidence_warning
+    action: verify_context
+    condition: "{{ui_lane}} == true"
+    require_true: ui_evidence_found
+    on_false: continue
+    on_false_message: >
+      Frontend lane '{{fe_lane_id}}' is declared at {{fe_root}}, but the scan found no
+      component, view or build-config files under that path ({{frontend_file_count}}
+      file(s) there in total). The UI governance authored below is reverse-engineered
+      from that subtree, so it will be thin or empty. Check that the source path points
+      at the directory holding the UI — /appweaver select-stack can move it — or
+      retire the lane there with (none) if this repo has no UI yet.
+
+  # 2. Pre-execution hooks.
+  - id: resolve_pre_hooks
+    action: execute_script
+    script: { ref: actions }
+    subcommand: resolve-hooks
+    args: ["--phase", "before_onboard"]
+    outputs:
+      - { name: before_hooks, from: "$.hooks" }
+  - id: dispatch_pre_hooks
+    action: dispatch_hooks
+    hooks_from_variable: before_hooks
+
+  # 3. ENRICHMENT — turn the substrate into a HIGH-LEVEL OKF feature map. Context via
+  #    build_context (agent_generate reads the envelope): the factual substrate, the
+  #    OKF format authority, and an OPTIONAL DDD vocabulary aid for naming (no
+  #    migration/pipeline reference — this is development).
+  - id: ctx_author
+    action: build_context
+    context:
+      - { path: "{{inventory_json}}" }                        # the deterministic substrate (aggregate_signals etc.)
+      - { path: .appweaver/templates/okf-concept-template.md }  # OKF v0.1 format authority (frontmatter, index, log, rules) — format only, zero project content
+  - id: author_bundle
+    action: agent_generate
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      Act as the OKF enrichment agent for the Brownfield DEVELOPMENT onboard step.
+      Produce a CONFORMANT OKF v0.1 knowledge bundle at {{bundle_dir}} that is a
+      HIGH-LEVEL FEATURE MAP — a discovery index of the features/aggregates this
+      codebase contains, organized BY AGGREGATE ROOT — from the deterministic
+      substrate {{inventory_json}} (in context). Follow the OKF concept template in
+      context for format (frontmatter, index.md/log.md rules, cross-linking, hard rules).
+      Domain/scope hint (optional): {{USER_INPUT}}
+
+      THIS IS A MAP, NOT A DEEP REVERSE. Keep every feature concept SHALLOW — enough
+      to recognize and pick the feature to develop next. The deep per-feature reverse
+      (spec.md + design.md) is /appweaver adopt, run just-in-time when a feature is
+      about to be developed. Do NOT deep-model invariants/behaviour here.
+
+      Read the substrate first. Its `aggregate_signals` are CANDIDATE feature roots,
+      each with its files grouped by layer plus detected entities; `ui_attribution`
+      says which FRONTEND files serve which of those roots (and which serve none);
+      `git.history.churn` ranks significance; the category lists and `top_level_dirs`
+      fill in the rest.
+      Signals are input, not decisions — YOU draw the real feature boundaries:
+      - Merge a src module and its mirror test module into ONE feature (e.g.
+        src/.../MedicinalProducts + tests/.../MedicinalProducts → MedicinalProduct).
+      - Treat service-level / shared infrastructure (a shared persistence context,
+        cross-cutting adapters, host / service-defaults projects) as a Platform/Shared
+        concept, NOT a feature.
+      - Fold value objects, entities, domain events, commands and endpoints into the
+        feature that OWNS them — one feature concept, not one per type.
+      NAME EVERY CONCEPT IN THE CODE'S OWN VOCABULARY — read the identifiers the source
+      actually uses. "Aggregate", "entity" and "value object" are how aw-spec ORGANIZES a
+      feature map; they are not a claim that this codebase is modelled that way. Where the
+      code expresses its model differently, record what it does and keep the aw-spec
+      grouping around it.
+
+      Write the bundle (all paths under {{bundle_dir}}; bundle-relative links begin
+      with "/", per OKF §5.1):
+      - `index.md` (bundle root) — frontmatter EXACTLY `okf_version: "0.1"` and nothing
+        else; body = sections of bulleted links reusing each concept's `description`.
+      - `architecture/overview.md` (type: Reference) — the system at a glance. Its
+        `## Purpose` section MUST open with the whole solution/product name in bold
+        followed by "is a …" (e.g. "**Medicinal.Healthcare** is a …") — this bold token
+        is the PROJECT NAME the governance tier is named after, so get it right. Then:
+        the FEATURE MAP (each feature + one-line responsibility — NO seam/clean-torn
+        column, NO adopt-order), the tech stack, named external references / integration
+        points, and links to every other concept.
+      - `architecture/platform.md` (type: Reference) — the SHARED / cross-cutting
+        TECHNICAL note: the actual technology base (language, framework, persistence,
+        eventing, hosting), the shared infrastructure (persistence context, host /
+        service-defaults),
+        cross-cutting concerns (auth posture, concurrency, observability) AS-BUILT. This
+        is the evidence the technical constitution is scaffolded from — describe what the
+        code ACTUALLY does, mark anything stubbed/optional/inactive as such.
+      - `architecture/frontend.md` (type: Reference) — WRITE THIS ONLY IF the substrate's
+        `frontend_signals.present` is true; omit the file entirely otherwise (a backend-only
+        repo must not get one). It is the UI counterpart of the platform note and the
+        evidence the frontend lane's constitution is scaffolded from. Read the candidate
+        roots in `frontend_signals` and then READ REPRESENTATIVE UI SOURCE from their
+        component/route/store file lists, and record AS-BUILT: the lane root(s) and whether
+        the UI is separable or rendered inside the service tree; what it is built with (name
+        it from the code — the `framework_markers` are markers, not conclusions); how
+        components are organized and named; routing/navigation; where client state and
+        server data-fetching live; styling and any design-system or component library in
+        use; the accessibility, internationalization and error/loading-state handling the
+        code ACTUALLY exhibits; and the lane's build, lint and test tooling. State
+        inconsistency as inconsistency and absence as absence — an app with no
+        accessibility attributes is recorded as having none, never as needing them.
+        This note is also where the SHARED UI surface is recorded — `ui_attribution.
+        unattributed` lists the files serving no single aggregate (app shell, layout,
+        design system, global styles). Describe what they provide; they belong here
+        precisely because no slice owns them.
+      - `aggregates/<feature>.md` (type: Aggregate) — ONE per feature root, SHALLOW:
+        Responsibilities; the entities / value objects / domain events / commands / API
+        endpoints / persistence it OWNS (named at a glance from the signal's layer
+        files — a list, not a deep model); and the candidate `specs/<Feature>/` slice
+        name (feature = aggregate). Set `source_files` to the module's files, grouped
+        with YAML comment headers by each file's OWN folder — the path segment that
+        VARIES across the files after their shared parent (the layer folder in a
+        vertical slice; the tier project in an n-tier app; tests → a single `tests`
+        group). Do NOT impose a fixed Domain/Application/UI taxonomy — the CODE's
+        folders ARE the grouping. Set `timestamp` to the latest commit time across them.
+        Then set `ui_source_files` to the FRONTEND files that serve this aggregate,
+        grouped the same way. The substrate's `ui_attribution` proposes them per
+        aggregate — it is a NAME match, so confirm each against what the file actually
+        is and move or drop one it got wrong. Keep the key and leave it EMPTY where the
+        aggregate has no UI (and on a backend-only repo, where every concept has none);
+        never fold these paths into `source_files`, which stays the service surface.
+      - `aggregates/index.md` — the bounded-context / feature map (no frontmatter beyond
+        OKF index rules) linking every feature concept.
+      - An `index.md` in EVERY subdirectory (no frontmatter).
+      - `log.md` (bundle root) — first line under a `## <today's date>` heading must be
+        `Commit: ` + backtick + `{{head}}` + backtick (validator rule E4), then a
+        one-line Initialization entry noting the concept count.
+      Do NOT write a migration-backlog, a seam/clean-torn analysis, or an adopt-order —
+      those are migration artifacts and are out of scope for the development flow.
+
+      Provenance + safety (OKF hard rules):
+      - Stamp every concept `origin: reverse-engineered` and `generated_by:
+        aw-spec-onboard/1.6.0` in frontmatter.
+      - The CODE is the source of truth; capture what IS (quirks included), not what
+        SHOULD be. Where intent is unclear from code + git history, add a concrete
+        `open_questions` entry rather than inventing one.
+      - NEVER fabricate facts, and NEVER emit secrets/tokens/credentials/internal
+        hostnames — describe shape, never values.
+      - Write ONLY inside {{bundle_dir}}; do NOT modify any source file.
+      Report the bundle tree and the concept count by type.
+    outputs:
+      - { name: bundle_files, from: "$.files" }
+
+  - id: verify_authored
+    action: verify_context
+    require_non_empty: bundle_files
+    on_empty: stop
+    on_empty_message: "No feature-map files were written to {{bundle_dir}}. Ensure the substrate {{inventory_json}} has aggregate_signals and re-run."
+
+  # 4. CONFORMANCE gate — OKF v0.1 validator (errors block; warnings noted).
+  - id: validate_bundle
+    action: execute_script
+    script: { ref: inventory }
+    subcommand: validate
+    args: ["--bundle", "{{bundle_dir}}", "--repo-root", "{{root}}"]
+    outputs:
+      - { name: conformant,   from: "$.conformant" }
+      - { name: okf_errors,   from: "$.errors" }
+      - { name: okf_warnings, from: "$.warnings" }
+      - { name: concepts,     from: "$.concepts" }
+
+  - id: conformance_gate
+    action: verify_context
+    require_true: conformant
+    on_false: stop
+    on_false_message: "The OKF feature map at {{bundle_dir}} is NON-CONFORMANT (errors: {{okf_errors}}). Fix the reported ERRORs (unparseable frontmatter, missing `type`, malformed index.md/log.md) and re-run."
+
+  # ═══════════════ PART 2 — GOVERNANCE SCAFFOLD (project-level) ════════════════
+  # Establish the governing tier ONCE, from the feature map just written (the whole-
+  # repo vantage). No slice is adopted, so list-adopted returns slice_count=0 but STILL
+  # yields project_name / overview / project_context (domain evidence) and
+  # design_context (= overview + platform: the technical evidence) from the bundle.
+  # There is NO require_adopted gate here — that is the whole point of onboarding first.
+
+  - id: project_ctx
+    action: execute_script
+    script: { ref: revcon }
+    subcommand: list-adopted
+    outputs:
+      - { name: slice_count,     from: "$.slice_count" }
+      - { name: spec_context,    from: "$.spec_context" }     # at onboard = project_context (no specs yet)
+      - { name: design_context,  from: "$.design_context" }   # at onboard = overview + platform (the tech evidence)
+      - { name: project_context, from: "$.project_context" }  # overview + aggregates/index + platform + index
+      - { name: project_name,    from: "$.project_name" }
+      - { name: overview,        from: "$.overview" }
+
+  # Slugify + `brf-` prefix the domain name and create guardrails/projects/brf-<domain>/.
+  # Name: explicit arg → PROJECT name from the OKF overview → repo basename. Guarded
+  # against clobbering a project that already holds .md files.
+  - id: pack_setup
+    action: execute_script
+    script: { ref: revcon }
+    subcommand: project-setup
+    args: ["--name", "{{USER_INPUT}}", "--fallback", "{{project_name}}"]
+    outputs:
+      - { name: domain_slug,                from: "$.domain_slug" }
+      - { name: pack_dir,                   from: "$.pack_dir" }
+      - { name: domain_rule_bindings,              from: "$.domain_rule_bindings" }
+      - { name: domain_constitution_source, from: "$.domain_constitution_source" }
+      - { name: pack_present,               from: "$.pack_present" }
+
+  - id: pack_guard
+    action: verify_context
+    require_value: pack_present
+    equals: "false"
+    on_mismatch: stop
+    on_mismatch_message: "The project guardrails/projects/{{domain_slug}}/ already holds curated rule files — onboard would overwrite them. Back up or remove that folder to re-onboard, or amend it via /appweaver constitution."
+
+  # ── DOMAIN RULE SET (provisional, evidenced by the SCAN) ────────────────────
+  # Feed NEUTRAL shape skeletons (rev-templates/, zero content to leak) + the rule-
+  # partition authority + the project context (the feature map). NO adopted specs
+  # exist — the evidence is the OKF overview + aggregates/index + platform.
+  - id: ctx_pack
+    action: build_context
+    context:
+      - { path: "{{inventory_json}}" }                                                       # the COMPLETE deterministic scan substrate — read representative SOURCE from its file lists (the OKF map only SUMMARISES this)
+      - { path: .appweaver/orchestrator/rev-templates/domain-rule-bindings.skeleton.md, optional: true }
+      - { path: .appweaver/orchestrator/rev-templates/domain-rule-file.skeleton.md, optional: true }
+      - { path: .appweaver/orchestrator/rev-templates/domain-requirements.skeleton.md, optional: true }
+      - { path: .appweaver/RULE-PARTITION.md }                                                    # the rule-partition authority (which command reads what)
+    context_from: project_context
+  - id: author_pack
+    action: agent_generate
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      Scaffold the PROJECT-level DOMAIN RULE SET for **{{project_name}}** (domain
+      {{domain_slug}}) into guardrails/projects/{{domain_slug}}/domain/ (the dir exists),
+      plus the domain map guardrails/projects/{{domain_slug}}/domain-rule-bindings.md at the
+      project root. A project keeps its three rule classes in domain/ · service/ · frontend/
+      and both maps at its root; adopt reconciles this set in place, so a file written
+      anywhere else is unreachable.
+
+      EVIDENCE = THE CODE ITSELF (deep read), NOT the shallow map. The OKF FEATURE MAP in
+      context (architecture/overview.md, aggregates/index.md, architecture/platform.md)
+      only SUMMARISES the codebase. READ REPRESENTATIVE SOURCE to extract the real domain
+      rules: use {{inventory_json}} (in context) to locate the domain-carrying files —
+      entities, value objects, aggregates, domain events, invariant checks, validation —
+      across the aggregate_signals, and Read enough of them to state each rule from what
+      the code ACTUALLY enforces. Do NOT invent a rule the code does not evidence, and do
+      NOT rely on the map alone. There are NO adopted specs yet; this is the whole-repo
+      vantage — describe the domain / bounded context AS A WHOLE, so any feature later
+      slots in without a rewrite.
+
+      CONCERNS HINT: {{USER_INPUT}} may carry a "concerns: a, b, c" clause. Treat any listed
+      concern as a SEARCH HINT — go look for it in the code — but you still DECIDE presence
+      from evidence: include a concern's rule file ONLY if the code exhibits it, drop a
+      listed concern the code shows none of, and ADD an unlisted concern the code clearly
+      evidences. Ignore any non-concerns text (the domain name / scope hint).
+
+      PROVISIONAL BY CONSTRUCTION. Because no slice is adopted, you have the domain's
+      SHAPE (its features, ubiquitous language, bounded-context map, evident concerns)
+      but not yet its enumerated rule ids. Write each rule at the level the feature map
+      evidences and mark unresolved specifics `PROVISIONAL — reconciled at adopt`
+      (adopt fills the exact BR-/CN-/DC-/IC- ids when the feature is developed). NEVER
+      invent a rule the code/feature-map does not evidence.
+
+      SKELETONS ARE SHAPE ONLY. The *.skeleton.md files (rev-templates/) show HEADINGS,
+      frontmatter, the rule-partition and tone — and carry NO domain content. Copy the
+      SHAPE; never treat a bracketed [TOKEN] or example marker as a value to assert.
+
+      EVIDENCED-ONLY (lean): write a `<concern>.domain.md` ONLY for a concern the
+      feature map / platform note actually exhibits. NAME EACH FILE AFTER THE CONCERN THE
+      CODE EXHIBITS, never after a methodology the code may not follow — a filename is an
+      assertion too. Consider, include only if evidenced:
+        - domain-model.domain.md         — the ubiquitous language + bounded-context /
+          feature map, WHAT this codebase's model is. Written wherever the code carries a
+          discernible domain model; omitted where it carries none (a pure script/ETL repo).
+          This is the domain tier's authority for /specify.
+        - data-classification.domain.md   — only if the overview shows classified data.
+        - auditing.domain.md              — only if the platform note shows audit/immutability.
+        - authorization.domain.md         — only if an auth posture is evident.
+        - persistence.domain.md           — only if retention/immutability/no-hard-delete is evident.
+        - cqrs.domain.md                  — only if the platform note shows a command/query split.
+        - eventing.domain.md              — only if domain events are evident.
+        - api-versioning.domain.md        — only if the API surface is versioned.
+      Plus, as needed:
+        - a domain reference file per distinct domain identifier/standard the overview names.
+        - domain-requirements.md          — the PROJECT overview: open with a
+          `[DOMAIN: Bounded Contexts / Modules]` map (from the overview + aggregates
+          index), then per-subsection pointers, platform topology, governance overrides.
+      Stamp every file `origin: reverse-engineered`, `generated_by: aw-spec-onboard/1.6.0`,
+      and note the project is a provisional scaffold reconciled per slice at adopt.
+
+      domain-rule-bindings.md (MANDATORY — /specify's resolve-domain reads this exact filename).
+      Wire ONLY the files you generated, preserving the RULE PARTITION:
+        - `## /aw-spec-constitution` — `domain/domain-constitution.md` FIRST (the project's
+          charter; a later step in this same run authors it, so wire the bullet now), then the
+          domain identity/regulatory/interop files → domain principles.
+        - `## /aw-spec-specify`      — the FULL domain set (specify models the domain, lifts CN-/DC-/IC-).
+        - `## /aw-spec-design`       — `_None — design loads no domain file. Domain reaches design only through the spec._`
+        - `## /aw-spec-implement`    — `_None — implement loads no domain file. Domain reaches implement only through design.md._`
+        - `## /aw-spec-gate`         — the conformance-checklist set (the *.domain.md files).
+      Each bullet is a workspace-relative path `- guardrails/projects/{{domain_slug}}/domain/<file>`.
+      Write ONLY inside guardrails/projects/{{domain_slug}}/ (domain/ + the map). Report the
+      files written.
+    outputs:
+      - { name: pack_files, from: "$.files" }
+
+  - id: verify_pack
+    action: verify_context
+    require_non_empty: pack_files
+    on_empty: stop
+    on_empty_message: "No domain rule files were written to guardrails/projects/{{domain_slug}}/domain/. Ensure the feature map carries a modellable domain (a feature map + ubiquitous language) and re-run."
+  - id: require_domain_rule_bindings
+    action: verify_context
+    required_files: ["{{domain_rule_bindings}}"]
+
+  # ── DOMAIN CONSTITUTION SOURCE — <project>/domain/domain-constitution.md ────────────
+  # Named and placed exactly as a greenfield industry corpus names and places its charter,
+  # and already wired as the first `## /aw-spec-constitution` bullet by the step above.
+  - id: ctx_domain_source
+    action: build_context
+    context:
+      - { path: "{{domain_rule_bindings}}" }
+      - { path: .appweaver/orchestrator/rev-templates/domain-constitution.skeleton.md, optional: true }
+    context_from: project_context
+  - id: author_domain_source
+    action: agent_author
+    include_standards: false
+    output_target: { type: file, path: "{{domain_constitution_source}}" }
+    task: |
+      Author the DOMAIN CONSTITUTION SOURCE (the output target) — the human-readable
+      charter for the WHOLE PROJECT **{{project_name}}** (domain {{domain_slug}}),
+      scaffolded from the OKF feature map (architecture/overview.md, aggregates/index.md
+      — in context) and the generated project's domain-rule-bindings.md. Follow the SHAPE of the
+      neutral skeleton domain-constitution.skeleton.md (in context) — its Project-Identity
+      + Domain-Principle structure — so the normal /appweaver constitution can
+      re-derive the domain half later. The skeleton carries NO content; every value
+      comes from the feature-map evidence.
+
+      PROJECT CHARTER, NOT AN AGGREGATE SPEC, and PROVISIONAL (no slice adopted yet).
+      Structure:
+      - Title `# {{project_name}} Domain Constitution (as-built, provisional)` and a
+        one-line origin note (`origin: reverse-engineered`, today's date).
+      - `## Project Identity` — project name = {{project_name}}; mission (from the
+        overview Purpose); bounded-context / feature map (from the overview feature map +
+        aggregates/index.md — list the features AND named external references as
+        contexts); architecture posture (from platform.md).
+      - `## Domain Principles` — principles the domain embodies, TITLED by DOMAIN CONCERN
+        (not by a feature name), each a declarative rule that would hold across features.
+        Number with a stable "D1, D2, …" convention (the composed constitution assigns
+        exact roman numerals after the technology base). Cite the feature-map evidence;
+        mark any principle whose exact rule ids are not yet enumerable `PROVISIONAL —
+        reconciled at adopt`.
+      - AS-BUILT: state the rule the code evidences; do NOT prescribe an ideal it does
+        not meet, and do NOT create a debt/backlog (migration is a later phase) — simply
+        omit an aspiration the code shows none of.
+      - Reference (do not restate) the technology base and the project's rule files.
+      Return the charter markdown only.
+
+  # ── SPLIT CONSTITUTION — scaffold the two memory halves ──────────────────────
+  # Create the halves this project's LANES call for. The domain half is always created
+  # — domain is not a lane, it addends whichever halves exist — and the technical half
+  # only where a service lane is declared. `setup_tech_flag` carries that decision to
+  # EVERY setup-constitution call in this workflow, the UI one included: this command
+  # creates the always-present halves as a side effect of whatever else it is asked to
+  # do, so a later call without the flag silently recreates the half an earlier call
+  # was told to skip.
+  - id: setup_constitution
+    action: execute_script
+    script: { ref: actions }
+    subcommand: setup-constitution
+    args: ["{{setup_tech_flag}}"]
+    outputs:
+      - { name: constitution_technical_file, from: "$.constitution_technical_file" }
+      - { name: constitution_domain_file,    from: "$.constitution_domain_file" }
+
+  # TECHNICAL HALF — from the OKF overview + platform note (design_context), DOMAIN-FREE.
+  # The neutral technical shape skeleton is fed via CONTEXT (not the sticky standards
+  # set, which is empty), so nothing leaks into the Part-1 feature-map agent.
+  - id: ctx_technical
+    action: build_context
+    condition: "{{svc_lane}} == true"
+    context:
+      - { path: "{{constitution_technical_file}}" }
+      - { path: .appweaver/orchestrator/rev-templates/technical-constitution.skeleton.md, optional: true }
+      - { path: .appweaver/orchestrator/rev-templates/ai-rules.reference.md, optional: true }
+    context_from: design_context
+  - id: author_technical
+    action: agent_author
+    condition: "{{svc_lane}} == true"
+    include_standards: false
+    output_target: { type: file, path: "{{constitution_technical_file}}" }
+    task: |
+      Scaffold the TECHNICAL project constitution (the target file in context) —
+      AS-BUILT, from the OKF architecture overview + platform note (in context) that
+      describe this codebase's ACTUAL technology base. It is a TEMPLATE with [ALL_CAPS]
+      tokens; this is the domain-AGNOSTIC half. No slice is adopted, so the evidence is
+      the SCAN (overview stack + platform note), and principles are PROVISIONAL —
+      reconciled with real code coordinates when features are adopted.
+
+      EVIDENCE-FIRST — DISCOVER the principle set; do NOT inherit it. The skeleton
+      (technical-constitution.skeleton.md, in context) is a NEUTRAL SHAPE REFERENCE ONLY
+      — heading style, Sync-Impact-Report shape, evidence-line pattern — and carries NO
+      principle set. Author a principle ONLY for a technology trait the platform note /
+      overview actually evidences (the framework, persistence, eventing, concurrency,
+      hosting, testing, auth posture that ARE there). Cite the evidence on every
+      principle (e.g. "(evidence: platform.md persistence; overview stack)"); mark it
+      `PROVISIONAL — code coordinate reconciled at adopt` where the exact file/type is
+      not yet pinned.
+      - State PARTIAL / STUBBED / OPTIONAL traits AT THE LEVEL THE CODE REACHES, never a
+        template ideal (e.g. permissive-stub auth is not "Security by Default").
+      - OMIT pure-aspiration traits the platform note shows ZERO of. Do NOT create an
+        as-built-debt/backlog sink — migration is a separate later phase; an unmet ideal
+        is simply not asserted here.
+      - The project name is **{{project_name}}** — use it for the title / any
+        [PROJECT_NAME] token so this half, the domain half, and the charter name the
+        SAME project (never the outer tooling folder or a namespace).
+      - Do NOT add any domain-specific principle, identifier, terminology, regulatory or
+        interop rule — those belong to constitution.domain.md.
+      - NUMBER the discovered principles with sequential roman numerals from I, NO gaps,
+        NO padding. STATE the hand-off in the Sync Impact Report ("Technical principles:
+        I–<N>; domain half continues at <N+1>").
+      - Fill EVERY placeholder; leave no unexplained [BRACKET] (justify a genuine
+        deferral as TODO(<FIELD>): reason). Bump CONSTITUTION_VERSION by semver; ISO
+        YYYY-MM-DD dates (RATIFICATION_DATE = today). Preserve heading hierarchy.
+      - PREPEND a "Sync Impact Report" HTML comment: version old→new, the DISCOVERED
+        principle set, any trait DELIBERATELY OMITTED for lack of evidence (with why),
+        the technical count / domain hand-off numeral, and dependent artifacts (✅/⚠).
+      Return the complete updated technical constitution content only.
+
+  - id: technical_validation_loop
+    action: loop
+    condition: "{{svc_lane}} == true"
+    while: "{{technical_ok}} != true"
+    max_iterations: 3
+    steps:
+      - id: tech_lint
+        action: execute_script
+        script: { ref: actions }
+        subcommand: constitution-verify
+        args: ["--file", "{{constitution_technical_file}}"]
+        outputs:
+          - { name: technical_ok,     from: "$.ok" }
+          - { name: technical_issues, from: "$.issues" }
+      - id: tech_lint_break
+        action: break
+        condition: "{{technical_ok}} == true"
+      - id: patch_technical
+        action: agent_author
+        context: ["{{constitution_technical_file}}"]
+        include_standards: false
+        output_target: { type: file, path: "{{constitution_technical_file}}" }
+        task: |
+          Fix these mechanical defects in the technical constitution (target file in
+          context), changing NOTHING else — preserve every principle, the heading
+          hierarchy, and the Sync Impact Report. Fill any listed [ALL_CAPS] placeholder
+          with concrete text (or a justified TODO(<FIELD>): reason); make the body's
+          version line AGREE with the Sync Impact Report; ISO YYYY-MM-DD dates.
+          Defects: {{technical_issues}}
+          Return the complete updated technical constitution content only.
+
+  # ── UI HALF (frontend lane only) ────────────────────────────────────────────
+  # Placed HERE for the same reason the greenfield constitution places it here: AFTER
+  # the technical half, so the service lane's rules cannot leak into the lane's own
+  # base, and BEFORE the domain half, so no domain file can leak into either. Domain
+  # reaches the UI lane through the spec, exactly as it reaches the service lane.
+  #
+  # The direction is INVERTED from greenfield. There, this half ratifies the project's
+  # mapped frontend rule files; here those files do not exist yet, so the evidence is
+  # the UI SOURCE — read through the scan substrate — and the project is generated
+  # afterwards as the detail layer under whatever this half ratifies. That is the same
+  # order the technical tier already uses in this workflow.
+
+  # Create the UI half from its template — on demand, unlike the other two. Its
+  # ABSENCE is meaningful: a repo with no UI never gets the file at all.
+  - id: setup_ui_constitution
+    action: execute_script
+    condition: "{{ui_lane}} == true"
+    script: { ref: actions }
+    subcommand: setup-constitution
+    args: ["--ui", "{{setup_tech_flag}}"]
+    outputs:
+      - { name: constitution_ui_file, from: "$.constitution_ui_file" }
+      - { name: ui_created,           from: "$.ui_created" }
+
+  - id: ctx_ui
+    action: build_context
+    condition: "{{ui_lane}} == true"
+    context:
+      - { path: "{{constitution_ui_file}}" }                                          # the target half being filled
+      - { path: "{{inventory_json}}" }                                                # PRIMARY: the COMPLETE deterministic substrate — frontend_signals + the UI file lists to read source from
+      - { path: .appweaver/orchestrator/rev-templates/ui-constitution.skeleton.md, optional: true }  # SHAPE ONLY: heading style, Sync-Impact-Report shape, evidence-line pattern (zero UI content)
+      - { path: "{{bundle_dir}}/architecture/frontend.md", optional: true }            # SECONDARY (shallow): the OKF as-built frontend note — corroborate, don't rely on alone
+  - id: author_ui
+    action: agent_author
+    condition: "{{ui_lane}} == true"
+    include_standards: false
+    output_target: { type: file, path: "{{constitution_ui_file}}" }
+    task: |
+      Scaffold the USER EXPERIENCE constitution — the FRONTEND LANE's half (the target
+      file in context) — for **{{project_name}}**, AS-BUILT and PROVISIONAL. It is a
+      TEMPLATE with [ALL_CAPS] tokens. This half is domain-AGNOSTIC, like the technical
+      base it runs parallel to.
+      Why this lane was detected: {{ui_evidence}}
+      Lane declaration: {{ui_declaration_note}}
+      User hint (optional, may name nothing about the UI): {{USER_INPUT}}
+
+      EVIDENCE = THE UI CODE ITSELF (deep read). Authority, in order:
+        1. THE ACTUAL UI SOURCE (ground truth). Use {{inventory_json}} (in context):
+           `frontend_signals` lists the candidate lane roots with their kind
+           (spa / server-rendered / desktop), their framework markers, and their
+           component / route / store / style file lists. READ ENOUGH OF THOSE FILES to
+           state each principle from what the UI ACTUALLY does. Do NOT assert an
+           experience trait you have not seen in the code.
+        2. The OKF architecture/frontend.md note (in context, if present) — SECONDARY,
+           shallow corroboration only.
+      The `framework_markers` are MARKERS, not conclusions — name the stack from the code.
+      Never carry over a principle, a folder convention, an accessibility target or a
+      quality gate from a greenfield UI template, another project, or your own experience
+      of how frontends are usually governed. If this code does not show it, it is not a
+      principle here.
+
+      EVIDENCE-FIRST — DISCOVER the principle set; do NOT inherit it. The skeleton
+      (ui-constitution.skeleton.md, in context) is a NEUTRAL SHAPE REFERENCE ONLY and
+      names no framework, router, component library, design system or conformance
+      standard. Copy the SHAPE; discover the CONTENT from the code.
+      - `## Declared Lane` — name the lane, what it is built with, and the root it owns,
+        ALL READ FROM THE CODE. Where the UI is rendered inside the service tree and owns
+        no root of its own, say exactly that: it is a legitimate as-built lane, reversed
+        in place. Where a declaration exists and disagrees with the code, REPORT the
+        disagreement rather than resolving it silently.
+      - Author a UX principle ONLY for an experience trait the UI code evidences, and cite
+        the evidence inline on each one (e.g. "(evidence: <real component/route/store
+        path>)"). State PARTIAL / INCONSISTENT / ABSENT traits at the level the code
+        actually reaches — an app with no accessibility attributes does not get an
+        accessibility principle written as though it were met.
+      - OMIT a concern the UI shows ZERO of. Do NOT create a debt/backlog sink —
+        modernization is a separate later phase, and an unmet ideal is simply not asserted.
+      - Where the codebase is INCONSISTENT, state the DOMINANT convention as the rule and
+        record the divergence with its coordinates. Do not pick a winner the code has not.
+      - NUMBER the principles as a UX-* series (UX-I, UX-II, …). Do NOT continue the
+        technical half's numbering or the domain half's — this half is PARALLEL to the
+        technical base, so its series is unaffected by how many principles that base has.
+      - This half stands ALONE as the frontend lane's base: it neither restates the service
+        lane's principles nor cites them by number. Add NO domain-specific principle,
+        identifier, terminology or regulatory rule — those belong to constitution.domain.md.
+      - Keep every path under the lane's own root. This half never adds to the service
+        lane's folder structure.
+      - The project name is **{{project_name}}** — use it for the title / any [PROJECT_NAME]
+        token, so all the halves name the SAME project.
+      - Mark the half PROVISIONAL: it is scaffolded from the whole-repo scan, and a later
+        adopt / constitution run reconciles it against per-slice evidence.
+      - Fill EVERY placeholder; leave no unexplained [BRACKET] (justify a genuine deferral
+        as TODO(<FIELD>): reason). Bump CONSTITUTION_VERSION by semver — this half versions
+        independently of the other two. ISO YYYY-MM-DD dates (RATIFICATION_DATE = today).
+        Preserve heading hierarchy.
+      - PREPEND a "Sync Impact Report" HTML comment: version old→new, the lane, the
+        DISCOVERED UX principle set, any experience concern DELIBERATELY OMITTED for lack
+        of evidence (with why), and dependent artifacts (✅/⚠).
+      Return the complete updated UI constitution content only.
+
+  - id: ui_validation_loop
+    action: loop
+    condition: "{{ui_lane}} == true"
+    while: "{{ui_ok}} != true"
+    max_iterations: 3
+    steps:
+      - id: ui_lint
+        action: execute_script
+        script: { ref: actions }
+        subcommand: constitution-verify
+        args: ["--file", "{{constitution_ui_file}}"]
+        outputs:
+          - { name: ui_ok,     from: "$.ok" }
+          - { name: ui_issues, from: "$.issues" }
+      - id: ui_lint_break
+        action: break
+        condition: "{{ui_ok}} == true"
+      - id: patch_ui
+        action: agent_author
+        context: ["{{constitution_ui_file}}"]
+        include_standards: false
+        output_target: { type: file, path: "{{constitution_ui_file}}" }
+        task: |
+          Fix these mechanical defects in the UI constitution (target file in context),
+          changing NOTHING else — preserve every principle, the UX-* numbering, the heading
+          hierarchy, and the Sync Impact Report. Fill any listed [ALL_CAPS] placeholder with
+          concrete text (or a justified TODO(<FIELD>): reason); make the body's version line
+          AGREE with the Sync Impact Report; ISO YYYY-MM-DD dates.
+          Defects: {{ui_issues}}
+          Return the complete updated UI constitution content only.
+
+  # The UI half's lint verdict only carries meaning where a lane exists. On a backend-only
+  # repo no half was created, so the run reports that rather than a bare false a reader
+  # would take for a half that needs a manual touch.
+  - id: ui_validation_state_absent
+    action: set
+    vars: { ui_validation_state: "n/a — no frontend lane, no UI half authored" }
+  - id: ui_validation_state_present
+    action: set
+    condition: "{{ui_lane}} == true"
+    vars: { ui_validation_state: "{{ui_ok}}" }
+
+  # DOMAIN HALF — from the project + charter, principles continue the technical numbering.
+  - id: ctx_domain
+    action: build_context
+    context:
+      - { path: "{{constitution_domain_file}}" }
+      - { path: "{{constitution_technical_file}}" }   # to CONTINUE its numbering (evidenced-only ⇒ not a fixed XV)
+      - { path: "{{domain_constitution_source}}" }
+      - { path: "{{domain_rule_bindings}}" }
+    context_from: project_context
+  - id: author_domain
+    action: agent_author
+    include_standards: false
+    output_target: { type: file, path: "{{constitution_domain_file}}" }
+    task: |
+      Scaffold the DOMAIN ADDENDA constitution for the WHOLE PROJECT **{{project_name}}**
+      (domain {{domain_slug}}) — the target file in context — AS-BUILT and PROVISIONAL,
+      from the OKF project context (overview, aggregates/index — in context) + the
+      domain-constitution source + the generated project (domain-rule-bindings in context; READ
+      the project's rule files under guardrails/projects/{{domain_slug}}/). It is a TEMPLATE
+      with [ALL_CAPS] tokens; this half carries ONLY domain material.
+      - Name the SAME project as the technical half / charter: title / any [PROJECT_NAME]
+        token = {{project_name}}. This is a PROJECT constitution, not an aggregate spec —
+        govern the domain / bounded context as a whole.
+      - Fill EVERY template placeholder — an unfilled one keeps this half out of the
+        composed constitution. Brackets of your OWN in the prose are fine: a regulation,
+        standard or identifier the domain actually cites is content, not a leftover slot.
+      - ADOPTED MODELLING STANDARD: name the methodology the technical half actually
+        mandates and cite that principle BY ITS ACTUAL NUMERAL, read from
+        constitution.technical.md in context. That half is evidenced-only here, so the
+        numeral is whatever the code supported — never a value carried over from another
+        constitution. If it mandates no modelling methodology, say so plainly rather than
+        supplying one.
+      - Author ONLY the domain layer: domain principles, domain folder additions,
+        regulatory/security posture, domain governance — from the project + charter. NUMBER
+        them by CONTINUING the technical half's roman numerals: READ
+        constitution.technical.md (in context), find its LAST numeral N, start the first
+        domain principle at N+1 (do NOT assume it ends at XV). TITLE each by DOMAIN
+        CONCERN (not a feature name); state which technical principle (by its ACTUAL
+        numeral) it EXTENDS. Do NOT restate the technical principles — reference them.
+        Mark any principle whose exact rule ids are not yet enumerable `PROVISIONAL —
+        reconciled at adopt`.
+      - Include a short domain identity / bounded-context map (from the charter).
+      - AS-BUILT: the principle is what the code evidences; do NOT introduce a domain
+        rule the feature map does not evidence, and do NOT create a debt/backlog.
+      - Bump CONSTITUTION_VERSION by semver; ISO YYYY-MM-DD dates. Preserve heading
+        hierarchy. PREPEND a "Sync Impact Report" HTML comment (version old→new, domain
+        principles, dependent artifacts ✅/⚠ + TODOs).
+      Return the complete updated domain addenda content only.
+
+  - id: domain_validation_loop
+    action: loop
+    while: "{{domain_ok}} != true"
+    max_iterations: 3
+    steps:
+      - id: dom_lint
+        action: execute_script
+        script: { ref: actions }
+        subcommand: constitution-verify
+        args: ["--file", "{{constitution_domain_file}}"]
+        outputs:
+          - { name: domain_ok,     from: "$.ok" }
+          - { name: domain_issues, from: "$.issues" }
+      - id: dom_lint_break
+        action: break
+        condition: "{{domain_ok}} == true"
+      - id: patch_domain
+        action: agent_author
+        context: ["{{constitution_domain_file}}"]
+        include_standards: false
+        output_target: { type: file, path: "{{constitution_domain_file}}" }
+        task: |
+          Fix these mechanical defects in the domain addenda constitution (target file
+          in context), changing NOTHING else — preserve every principle, the heading
+          hierarchy, and the Sync Impact Report. Fill any listed [ALL_CAPS] placeholder
+          (or a justified TODO(<FIELD>): reason); make the body version AGREE with the
+          Sync Impact Report; ISO YYYY-MM-DD dates.
+          Defects: {{domain_issues}}
+          Return the complete updated domain addenda content only.
+
+  # ── COMPOSE + ACTIVATE ───────────────────────────────────────────────────────
+  - id: compose_constitution
+    action: execute_script
+    script: { ref: actions }
+    subcommand: compose-constitution
+    outputs:
+      - { name: composed_file,     from: "$.composed_file" }
+      - { name: domain_included,   from: "$.domain_included" }
+      # The UI half appends after the two roman-numeral halves and runs its own UX-*
+      # series, so it never enters the numbering check below.
+      - { name: ui_included,       from: "$.ui_included" }
+      - { name: numbering_ok,      from: "$.numbering_ok" }
+      - { name: numbering_issues,  from: "$.issues" }
+      - { name: technical_last,    from: "$.technical_last" }
+      - { name: domain_first,      from: "$.domain_first" }
+
+  # Numbering gate — the twin of the greenfield constitution workflow's. Brownfield
+  # needs it MORE, not less: the technical half here is evidenced-only, so its length is
+  # discovered from the code rather than fixed by a mapped base, and the domain half is
+  # authored in the same run against a numeral it has just been told to read. Announce
+  # and continue: both halves are written and the composed view shows the clash.
+  # Ordered override — the var holds "ok" unless the check reported a problem, because
+  # require_non_empty reports on EMPTY.
+  - id: numbering_default
+    action: set
+    vars: { numbering_gate: "ok" }
+  - id: numbering_detect
+    action: set
+    condition: "{{numbering_ok}} == false"
+    vars: { numbering_gate: "" }
+  - id: numbering_warning
+    action: verify_context
+    require_non_empty: numbering_gate
+    on_empty: continue
+    on_empty_message: >
+      Principle numbering does not run cleanly across the reverse-engineered halves:
+      {{numbering_issues}} (technical half ends at {{technical_last}}, domain half starts
+      at {{domain_first}}). The technical half is evidenced-only, so its last numeral is
+      whatever the code actually supported — the domain half must resume from the number
+      FOLLOWING it, never from a fixed value. Renumber the domain half in
+      .appweaver/memory/constitution.domain.md and re-run compose; the composed
+      constitution.md was still written so the clash is visible.
+
+  # Auto-activate: point .appweaver/domain.json at the scaffolded project so the forward CR
+  # loop governs development with it from the first change.
+  - id: activate_domain
+    action: execute_script
+    script: { ref: actions }
+    subcommand: set-domain
+    args: ["--domain", "{{domain_slug}}"]
+    outputs:
+      - { name: active_domain, from: "$.domain" }
+      - { name: map_exists,    from: "$.map_exists" }
+
+  # ═══════════ TECHNICAL RULE SET (code-derived) — the technical twin of the ═══════
+  #            domain set above. This is what stops adopt AND the whole forward
+  #            pipeline from falling back to greenfield technical rules.
+  #
+  # Runs AFTER the technical constitution is authored + validated (technical_validation_loop)
+  # so its ratified principles are on hand: each generated tech rule file is the DETAIL layer
+  # under a constitution.technical.md principle (thin ratified line ↑ / enforceable rule ↓).
+  # Evidence = the CODE (deep read via inventory_json's file lists) + the validated technical
+  # constitution + the shallow platform note (corroboration only). Writes:
+  #   1. guardrails/projects/<domain>/service/<concern>.md — evidenced-only code-derived tech rule
+  #      files (the ANALOG of a greenfield project's architecture · security · governance set, but reverse-
+  #      engineered from THIS code, never a greenfield file), INCLUDING the one file that
+  #      feeds /specify: service/domain-modelling.md, the as-built modelling METHODOLOGY (the
+  #      analog of the greenfield corpus's technology/<stack>/domain-driven-design.md). Without it brownfield
+  #      specify has a model but no HOW-to-model standard, and models a NEW feature in a
+  #      different idiom than the code it joins, and
+  #   2. guardrails/projects/<domain>/tech-rule-bindings.md — the TECHNICAL map (resolve-tech +
+  #      tech-select read it by that exact name), wiring the generated files per-workflow.
+  # Because onboard already ACTIVATED brf-<domain>, the forward pipeline's + adopt's tech_select
+  # steps now resolve to THESE files — never another project's rules, ever. The project
+  # lives inside pack_dir, so pack_guard (above) already protects it from clobber.
+  - id: ctx_tech_pack
+    action: build_context
+    condition: "{{svc_lane}} == true"
+    context:
+      - { path: "{{inventory_json}}" }                                                          # PRIMARY: the COMPLETE deterministic substrate — read representative SOURCE from its file lists
+      - { path: "{{constitution_technical_file}}" }                                             # PRIMARY: the VALIDATED as-built technology base — the ratified principles these files detail
+      - { path: .appweaver/orchestrator/rev-templates/tech-rule-bindings.skeleton.md, optional: true }   # SHAPE ONLY: the technical map's headings + partition + table (zero real files)
+      - { path: .appweaver/orchestrator/rev-templates/technical-rule-file.skeleton.md, optional: true }  # SHAPE ONLY: one code-derived tech rule file's shape (zero real tech)
+      - { path: .appweaver/RULE-PARTITION.md }                                                    # the rule-partition authority (which command reads what)
+      - { path: "{{bundle_dir}}/architecture/platform.md", optional: true }                     # SECONDARY (shallow): the OKF as-built platform note — corroborate, don't rely on alone
+    context_from: design_context
+  - id: author_tech_pack
+    action: agent_generate
+    condition: "{{svc_lane}} == true"
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      Scaffold the PROJECT-level TECHNICAL RULE SET for **{{project_name}}** (domain
+      {{domain_slug}}) — the CODE-DERIVED replacement for the greenfield technical rule set —
+      into guardrails/projects/{{domain_slug}}/service/ (create it), plus the technical map
+      guardrails/projects/{{domain_slug}}/tech-rule-bindings.md. This is the TECHNICAL twin of the
+      already-generated domain set: it feeds the HOW phases (design/implement/build/…) plus
+      ONE modelling-methodology file for /specify (see domain-modelling below) — and nothing
+      else ever reaches /specify from this tier.
+
+      EVIDENCE = THE CODE ITSELF (deep read) + THE VALIDATED TECHNICAL CONSTITUTION. Authority,
+      in order:
+        1. THE ACTUAL SOURCE CODE (ground truth). Use {{inventory_json}} (in context) to locate
+           representative files across top_level_dirs + a few aggregate_signals, and Read enough
+           to state each technical rule from what the code ACTUALLY does — the folder/tier/module
+           convention, the dependency direction, the persistence approach, concurrency handling,
+           testing convention, the auth/cross-cutting posture. Do NOT assert structure you have
+           not seen in the code.
+        2. constitution.technical.md (in context) — the VALIDATED as-built technology base. Each
+           generated tech rule file is the DETAIL under one of ITS principles; cite the principle
+           numeral on the rules it details. Never contradict it; never restate it wholesale.
+        3. The OKF platform.md (in context, if present) — SECONDARY, shallow corroboration only.
+      NEVER reference, read, copy, or list a rule file belonging to another project
+      (guardrails/projects/<other>/**) — those are the
+      greenfield fixture, NOT this project's rules. Every path you write lives under
+      guardrails/projects/{{domain_slug}}/service/.
+
+      CONCERNS HINT: {{USER_INPUT}} may carry a "concerns: a, b, c" clause. Treat any listed
+      concern as a SEARCH HINT — look for it in the code — but DECIDE presence from evidence:
+      write a tech rule file for a concern ONLY if the code exhibits it, drop a listed concern
+      the code shows none of, and ADD an unlisted concern the code clearly evidences. Ignore any
+      non-concerns text.
+
+      EVIDENCED-ONLY (lean). Write a `service/<concern>.md` ONLY for a technology concern the code
+      actually exhibits — e.g. as-built-architecture, persistence, concurrency, testing,
+      security-posture, api-surface, eventing, observability, hosting. Follow the SHAPE of
+      technical-rule-file.skeleton.md (in context): frontmatter (origin: reverse-engineered,
+      generated_by: aw-spec-onboard/1.6.0, concern), a one-line framing, rules each citing a CODE
+      COORDINATE (real file/folder path or named type) + the constitution principle numeral where
+      it maps. The skeleton carries NO real technology — copy the shape only. State stubs/partials
+      AS-BUILT (do not upgrade a stub into a greenfield ideal); omit a concern the code shows none
+      of (migration is a separate later phase — no debt/backlog sink here).
+
+      PLUS ONE SPECIAL FILE — `service/domain-modelling.md` (concern: domain-modelling). This is the
+      ONE file in this project that feeds /specify, and it is a MODELLING METHODOLOGY: HOW this
+      codebase expresses a domain model, not WHAT the model is (the model itself is the domain
+      project's domain-model file, already written — do NOT restate or duplicate it).
+      Read the code and state the AS-BUILT modelling conventions, each citing a code coordinate:
+        - what marks an aggregate root, and how a root is reached (base class / marker interface
+          / naming), plus the identity convention (typed id? primitive? value object?);
+        - entity vs value object — how the code distinguishes them, and where each lives;
+        - where invariants actually live (root method / domain service / validator / DB
+          constraint) — state what the code DOES, even if that is "enforced in the handler";
+        - the bounded-context / module boundary and what may cross it (ids only? DTOs? entities?);
+        - domain events, if the code has them: what raises one, and where it is dispatched;
+        - the naming/ubiquitous-language convention the code visibly follows.
+      Write it even when the conventions are partial or inconsistent — say so AS-BUILT and cite
+      the divergent coordinates; that is exactly what /specify needs in order to model a NEW
+      feature the way this codebase already models. Contains NO business vocabulary and NO
+      technology/architecture rules (those are the other files). Omit this file ONLY if the code
+      has no discernible domain model at all (e.g. a pure script/ETL repo).
+
+      tech-rule-bindings.md (MANDATORY — resolve-tech + the tech-select module read this exact
+      filename). Follow the SHAPE of tech-rule-bindings.skeleton.md (in context) and the rule
+      partition (.appweaver/RULE-PARTITION.md, in context). Wire ONLY files you generated, under these headings, and
+      ONLY a heading you have a generated file for (an absent heading soft-continues → loads
+      nothing):
+        - `## /aw-spec-specify`         — EXACTLY ONE bullet: `service/domain-modelling.md`, the modelling methodology. NEVER an architecture / persistence / codegen / security file here — specify is the domain phase and any technology rule under this heading breaks its domain purity. Omit the heading only if you did not write domain-modelling.md.
+        - `## /aw-spec-design`          — the as-built architecture / cross-cutting rules the design author mediates the spec against.
+        - `## /aw-spec-implement`        — the code-generation / convention set the generator builds against (from design.md).
+        - `## /aw-spec-implement-delta`  — the same code-generation set, scoped to a change's delta-design.
+        - `## /aw-spec-build`            — the layering + convention rules the compile-fixer respects.
+        - `## /aw-spec-analyze-slice`    — the conformance rules the design↔code gate validates against.
+        - `## /aw-spec-adopt`            — the technical reference set the reversed design mediates against (a subset of design's).
+        - `## /aw-spec-constitution`     — the standards a later `/appweaver constitution` re-ratifies the TECHNICAL half from. You authored that half from code evidence before these files existed; this heading is what makes a re-run author from THIS project's rules rather than from an empty set. Ratifiable standards only, no worked `examples/` sample, no domain file.
+        - `## /aw-spec-run`              — the runtime / execution conventions the app-run step honors (add ONLY if the code evidences a runtime/hosting concern file; NOT data-migration — migration is the deferred later phase).
+      Each bullet is a
+      workspace-relative path `- guardrails/projects/{{domain_slug}}/service/<file>`. Close with the
+      quick-reference table. Write ONLY inside guardrails/projects/{{domain_slug}}/ (service/ + the map);
+      modify no source. Report the files written + the concerns you found present (with the code
+      paths that evidence them).
+    outputs:
+      - { name: tech_pack_files, from: "$.files" }
+
+  - id: verify_tech_pack
+    action: verify_context
+    condition: "{{svc_lane}} == true"
+    require_non_empty: tech_pack_files
+    on_empty: stop
+    on_empty_message: "No technical rule files were written to guardrails/projects/{{domain_slug}}/service/. Ensure the scan substrate (inventory_json) + the validated technical constitution carry an as-built technology base and re-run."
+  - id: require_tech_rule_bindings
+    action: verify_context
+    required_files: ["{{pack_dir}}/tech-rule-bindings.md"]
+
+  # Did the modelling methodology reach /specify? The map is the only route this tier has
+  # into the domain phase, and `## /aw-spec-specify` carrying service/domain-modelling.md
+  # is what stops brownfield specify from modelling a new feature in a different idiom
+  # than the code it joins. Read it back through the same resolver /specify uses — the
+  # project is already activated, so this asks the question exactly as specify will.
+  # Announce, don't stop: a repo with no discernible domain model legitimately has no such
+  # file, and the run's remaining work is worth keeping either way.
+  - id: probe_specify_wiring
+    action: execute_script
+    condition: "{{svc_lane}} == true"
+    on_error: continue
+    script: { ref: actions }
+    subcommand: resolve-tech
+    args: ["--command", "aw-spec-specify"]
+    outputs:
+      - { name: specify_rules, from: "$.candidates" }
+  - id: warn_specify_wiring
+    action: verify_context
+    condition: "{{svc_lane}} == true"
+    require_non_empty: specify_rules
+    on_empty: continue
+    on_empty_message: >
+      guardrails/projects/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      `## /aw-spec-specify`, so brownfield specify will model new features with no
+      as-built modelling methodology to follow. That is correct only where the code has no
+      discernible domain model (a pure script/ETL repo). Otherwise add
+      service/domain-modelling.md — HOW this codebase expresses a domain model, not what
+      the model is — and wire it as the single bullet under that heading.
+
+  # ═══════════ FRONTEND RULE SET (code-derived) — the LANE's tier ════════════════
+  # The third generated project, written only where the code has a UI. It is the DETAIL
+  # layer under the UX-* principles the half above ratified (thin ratified line ↑ /
+  # enforceable rule ↓), exactly as service/ is the detail layer under the technical half.
+  #
+  # Runs AFTER the technical set because both write the SAME map file: the technical set
+  # authors tech-rule-bindings.md, and this step APPENDS the lane's heading to it. That
+  # heading is what makes a later /appweaver constitution re-ratify the UI half from
+  # THIS project's lane rules — and it is also the authoritative signal that the project
+  # HAS a frontend lane, so writing it is what lets the greenfield constitution command
+  # find the lane on every future run without stacks.json or a named stack.
+  - id: ctx_ui_pack
+    action: build_context
+    condition: "{{ui_lane}} == true"
+    context:
+      - { path: "{{inventory_json}}" }                                                            # PRIMARY: the COMPLETE deterministic substrate — frontend_signals + the UI file lists to read source from
+      - { path: "{{constitution_ui_file}}" }                                                      # PRIMARY: the VALIDATED as-built UX-* base — the ratified principles these files detail
+      - { path: "{{pack_dir}}/tech-rule-bindings.md" }                                            # the map to APPEND to — read it so the edit preserves what the technical set wrote
+      - { path: .appweaver/orchestrator/rev-templates/frontend-rule-file.skeleton.md, optional: true }   # SHAPE ONLY: one code-derived lane rule file's shape (zero real UI tech)
+      - { path: .appweaver/orchestrator/rev-templates/tech-rule-bindings.skeleton.md, optional: true }   # SHAPE ONLY: the technical map's headings + partition + table
+      - { path: .appweaver/RULE-PARTITION.md }                                                      # the rule-partition authority (which command reads what)
+      - { path: "{{bundle_dir}}/architecture/frontend.md", optional: true }                       # SECONDARY (shallow): the OKF as-built frontend note
+  - id: author_ui_pack
+    action: agent_generate
+    condition: "{{ui_lane}} == true"
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      Scaffold the PROJECT-level FRONTEND RULE-FILE PACK for **{{project_name}}** (domain
+      {{domain_slug}}) — the CODE-DERIVED lane rules — into
+      guardrails/projects/{{domain_slug}}/frontend/ (create it), and WIRE it into the existing
+      guardrails/projects/{{domain_slug}}/tech-rule-bindings.md. This is the FRONTEND LANE's
+      twin of the service/ set you have already generated: it is the detail layer under
+      constitution.ui.md's UX-* principles, and it governs only code under the lane's root.
+
+      EVIDENCE = THE UI CODE ITSELF (deep read) + THE VALIDATED UI CONSTITUTION. Authority,
+      in order:
+        1. THE ACTUAL UI SOURCE (ground truth). Use {{inventory_json}} (in context):
+           `frontend_signals` gives the lane roots, their kind, their framework markers and
+           their component / route / store / style file lists. Read enough of those files to
+           state each rule from what the UI ACTUALLY does. Do NOT assert a convention you
+           have not seen in the code.
+        2. constitution.ui.md (in context) — the VALIDATED as-built UX-* base. Each file
+           here is the DETAIL under one of ITS principles; cite the UX numeral on the rules
+           it details. Never contradict it; never restate it wholesale.
+        3. The OKF architecture/frontend.md (in context, if present) — SECONDARY, shallow.
+      NEVER reference, read, copy, or list a rule file belonging to another project
+      (guardrails/projects/<other>/**) — those are the greenfield fixture, NOT this project's
+      rules. Never carry over a convention, an accessibility target, a folder taxonomy or a
+      quality gate from a greenfield UI rule file or from how frontends are usually built.
+      Every path you write lives under guardrails/projects/{{domain_slug}}/frontend/.
+
+      EVIDENCED-ONLY (lean). Follow the SHAPE of frontend-rule-file.skeleton.md (in context):
+      frontmatter (origin: reverse-engineered, generated_by: aw-spec-onboard/1.6.0, concern),
+      a one-line framing, then rules each citing a CODE COORDINATE (a real component / route /
+      store / stylesheet / config path) and the UX principle numeral where it maps.
+      - `frontend/ui-constitution.md` — ALWAYS, the lane's base file: the lane declaration
+        (id, what it is built with, the root it owns, whether it is separable or rendered
+        inside the service tree) plus the whole-lane rules. This is the file a later
+        /appweaver constitution re-ratifies the UI half from, so it must stand on its own.
+      - Then a `frontend/<concern>.md` ONLY for an experience concern the UI code actually
+        exhibits — e.g. component-model, routing-and-navigation, state-and-data,
+        styling-and-design-system, accessibility, interaction-states, forms-and-validation,
+        internationalization, performance, ui-testing. Drop any the code shows none of; add
+        any it clearly evidences that is not on that list.
+      State inconsistency AS-BUILT: give the DOMINANT convention as the rule and record the
+      divergence with its coordinates. Do not upgrade a partial into a greenfield ideal, and
+      do not create a debt/backlog sink — modernization is a separate later phase.
+
+      WIRE THE MAP — EDIT guardrails/projects/{{domain_slug}}/tech-rule-bindings.md IN PLACE.
+      It already exists and carries the technical headings you wrote; PRESERVE all of them
+      byte-for-byte. Make exactly two additions:
+        1. A `## /aw-spec-ui-constitution` section, placed after the last technical heading
+           and BEFORE the closing quick-reference table. Bullet ONLY the frontend files you
+           just generated, `frontend/ui-constitution.md` first, each as a workspace-relative
+           path `- guardrails/projects/{{domain_slug}}/frontend/<file>`. Ratifiable lane
+           standards only — no domain file, no technical file, no example. Precede them with
+           a short HTML comment saying what this half ratifies and that the heading is also
+           the authoritative signal that the project has a frontend lane.
+        2. Its row in the quick-reference table, in the same format as the existing rows.
+      Do NOT add `## /aw-spec-ui-design` or `## /aw-spec-ui-implement`: those commands do not
+      exist yet, and a heading mapping files for a command nobody runs is a claim the kit
+      cannot honour. They arrive with the UI lane's own phases.
+
+      Write ONLY inside guardrails/projects/{{domain_slug}}/ (frontend/ + the map edit); modify
+      no source. Report the files written, the concerns you found present with the code paths
+      that evidence them, and the concerns you deliberately omitted.
+    outputs:
+      - { name: ui_pack_files, from: "$.files" }
+
+  - id: verify_ui_pack
+    action: verify_context
+    condition: "{{ui_lane}} == true"
+    require_non_empty: ui_pack_files
+    on_empty: stop
+    on_empty_message: "A frontend lane was detected ({{ui_evidence}}) but no lane rule files were written to guardrails/projects/{{domain_slug}}/frontend/. Check that the scan substrate's frontend_signals carry readable UI source, then re-run."
+
+  # Did the lane's heading land in the map? The files above are only half the wiring:
+  # `## /aw-spec-ui-constitution` is what a later /appweaver constitution re-ratifies
+  # the UI half from, and it is the authoritative signal that this project HAS a lane.
+  # Written by an in-place edit, so read it back through the resolver that will look for
+  # it. Announce, don't stop — the rule files are on disk and the heading is one edit away.
+  - id: probe_ui_wiring
+    action: execute_script
+    condition: "{{ui_lane}} == true"
+    on_error: continue
+    script: { ref: actions }
+    subcommand: resolve-tech
+    args: ["--command", "aw-spec-ui-constitution"]
+    outputs:
+      - { name: ui_map_rules, from: "$.candidates" }
+  - id: warn_ui_wiring
+    action: verify_context
+    condition: "{{ui_lane}} == true"
+    require_non_empty: ui_map_rules
+    on_empty: continue
+    on_empty_message: >
+      The lane rule files were written to guardrails/projects/{{domain_slug}}/frontend/,
+      but guardrails/projects/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      `## /aw-spec-ui-constitution`. Without that heading a later /appweaver
+      constitution finds no lane rules to re-ratify the UI half from, and reads this
+      project as backend-only. Add the heading after the last technical one, bulleting
+      frontend/ui-constitution.md first, then the rest of the frontend/ set.
+
+  # ═══════════ LANE DECLARATION — read back, never written ═══════════════════════
+  # onboard does not declare lanes. It used to: before select-stack was the first
+  # command of this sequence, a repo could arrive here with no declaration at all, so
+  # onboard ran its own detection pass and recorded what it found, marked
+  # `origin: reverse-engineered` and gated never to overwrite a lane a person had
+  # confirmed. With the declaration now REQUIRED at the top of this workflow — it is
+  # what told the scan which subtrees to read — that gate can never open, and the
+  # detection pass was re-deriving an answer the run already had.
+  #
+  # So `lane-declare` is the sole writer again, with one caller: select-stack, where a
+  # person picks. That is a stronger property than the two-caller version, and it is
+  # still a grep rather than a convention.
+  #
+  # What remains is a read-back through the same reader every other workflow uses, so
+  # the run reports the lanes it actually scanned under rather than a second opinion
+  # about them.
+  - id: lane_readback
+    action: execute_script
+    on_error: continue
+    script: { ref: actions }
+    subcommand: lane-resolve
+    outputs:
+      - { name: stacks_file,     from: "$.path" }
+      - { name: declared_lanes,  from: "$.lanes" }
+      - { name: be_lane_root,    from: "$.backend_source_path" }
+      - { name: be_lane_profile, from: "$.backend_profile" }
+      - { name: fe_lane_root,    from: "$.frontend_source_path" }
+      - { name: fe_lane_profile, from: "$.frontend_profile" }
+
+  # ═══════════ CODE-DERIVED DESIGN TEMPLATES (reverse-engineered) ═══════════════
+  # Runs LAST in onboard — AFTER the governance tier is authored + validated + composed
+  # (compose_constitution above) — so the strongest reverse-engineered evidence is on hand:
+  # the ACTUAL SOURCE CODE + the deterministic scan substrate (inventory_json) + the
+  # VALIDATED technical constitution (the as-built technology base). Establish this repo's
+  # DESIGN CONVENTION by REVERSE-ENGINEERING its own technical structure into a project-
+  # specific design + delta-design template pair, written to the PROJECT-LEVEL override slot
+  # (.appweaver/templates/overrides/{design,delta-design}-template.md — resolve_template
+  # Priority-1). The forward `design` phase's brownfield branch (design-scaffold reports
+  # override_active ⇒ design_mode == bootstrap_bf) then authors EVERY new feature against the
+  # as-built architecture, and a CHANGE authors its delta-design against the SAME code-derived
+  # sections (cr-setup scaffolds the delta from resolve_template("delta-design-template") ⇒
+  # the override) — no adopt required, consistent with the master design.md adopt emits.
+  #
+  # GROUNDED IN CODE + REVERSE-ENGINEERED FILES ONLY. The Part-1 OKF feature map is a SHALLOW
+  # discovery index (by design — NOT a deep reverse), so it is NOT the authority: the section
+  # skeleton is derived from the CODE itself + inventory_json (complete, deterministic) + the
+  # validated technical constitution, with the OKF map as secondary corroboration.
+  #
+  # NO GREENFIELD TEMPLATE IS IN CONTEXT — this tier reads a NEUTRAL SKELETON from
+  # rev-templates/, exactly as the constitution halves and both rule sets already do. The
+  # greenfield design templates carry a Domain/Application/API/Infrastructure layering in
+  # their headings, their example rows and their authoring prose, and a prompt telling an
+  # author not to copy the exemplar in front of it is the weakest control this kit has.
+  # rev-templates/{design,delta-design}-template.skeleton.md carry the SAME neutral bones
+  # (header block, the §1.2 domain/data-model anchor, the traceability spine, the two
+  # deferral ledgers, Change History, the tech-agnostic authoring rules) with the layering
+  # removed and every structural section left as a slot the code fills. The generated
+  # template keeps the §0–§6 shape the forward `design` bootstrap_bf branch expects and the
+  # two anchors aw-xref keys on, so no workflow change is needed to consume it.
+  #
+  # WHERE A FRONTEND LANE EXISTS the lane gets its OWN pair (ui-design-template +
+  # ui-delta-design-template, below), so this pair covers the SERVICE lane only and excludes
+  # the lane's roots from the structure it derives. One lane's template never describes the
+  # other's code. Re-onboard is gated upstream (bundle_guard / pack_guard) — remove the OKF
+  # bundle to regenerate.
+
+  # DESIGN template — the code-derived evidence (code + inventory + technical constitution)
+  # plus a NEUTRAL skeleton for the bones. No greenfield template is in context.
+  - id: ctx_design_template
+    action: build_context
+    condition: "{{svc_lane}} == true"
+    context:
+      - { path: "{{inventory_json}}" }                                        # PRIMARY: the COMPLETE deterministic substrate (top_level_dirs, aggregate_signals' per-layer file groupings) — the OKF markdown only SUMMARISES this
+      - { path: "{{constitution_technical_file}}" }                           # PRIMARY: the VALIDATED as-built technology base (framework/persistence/concurrency/hosting/testing/cross-cutting)
+      - { path: .appweaver/orchestrator/rev-templates/design-template.skeleton.md }   # SHAPE ONLY: the neutral bones + the pinned anchors + tech-agnostic authoring rules (zero layering, zero technology)
+      - { path: .appweaver/DESIGN-FORMAT.md }                                   # the HLD contract + its Brownfield variant note (which anchors are pinned, and why)
+      - { path: "{{bundle_dir}}/architecture/platform.md", optional: true }   # SECONDARY (shallow): the OKF as-built platform note — corroborate, don't rely on alone
+      - { path: "{{bundle_dir}}/architecture/overview.md", optional: true }   # SECONDARY (shallow): the OKF feature map + stack
+      - { path: "{{bundle_dir}}/aggregates/index.md", optional: true }        # SECONDARY (shallow): the bounded-context / feature map
+  - id: gen_design_template
+    action: agent_generate
+    condition: "{{svc_lane}} == true"
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      REVERSE-ENGINEER this repo's design convention into a PROJECT-SPECIFIC design
+      TEMPLATE and Write it to .appweaver/templates/overrides/design-template.md (create the
+      overrides/ dir if absent). It is a TEMPLATE — concrete project-derived section HEADERS
+      with [PLACEHOLDER] tokens + authoring HTML comments the forward `design` phase fills
+      per feature — NOT a filled design.
+
+      GROUND EVERYTHING IN THE CODE + THE REVERSE-ENGINEERED FILES — not the shallow OKF map
+      and not any architecture you know from elsewhere. Evidence authority, in order:
+        1. THE ACTUAL SOURCE CODE (ground truth). Read REPRESENTATIVE source files across the
+           repo's top_level_dirs and a few aggregate_signals (from {{inventory_json}}) — enough
+           to CONFIRM from the code the recurring folder/tier/module convention + the dependency
+           direction it actually follows. Do NOT assert structure you have not seen in the code.
+        2. {{inventory_json}} — the COMPLETE deterministic scan substrate (top_level_dirs, each
+           aggregate_signal's files grouped by layer, categories, tech stack). The OKF markdown
+           only SUMMARISES this, shallowly — prefer the substrate + the code over it.
+        3. The TECHNICAL CONSTITUTION (constitution.technical.md, in context) — the VALIDATED
+           as-built technology base (framework, persistence, concurrency, hosting, testing,
+           cross-cutting posture). It is the authority for §1.1 As-Built Architecture + §3.
+        4. The OKF platform.md / overview.md / aggregates/index.md (in context, if present) —
+           SECONDARY, shallow corroboration only (Part 1 is a discovery map, NOT a deep
+           reverse). Never rely on them alone.
+
+      THE SKELETON IS SHAPE ONLY. rev-templates/design-template.skeleton.md (in context)
+      carries the neutral bones, the pinned anchors and the authoring rules — and NO layering,
+      NO architecture style and NO technology, because naming one would answer the question
+      this step exists to ask the code. Copy the SHAPE; discover the STRUCTURE. Never carry a
+      Domain/Application/API/Infrastructure layering — or any other reference architecture —
+      into §1.1 or §2 from memory. DESIGN-FORMAT.md (in context, § Brownfield variant) states
+      which anchors are pinned and why.
+
+      SERVICE LANE ONLY. Frontend lane roots this repo has: {{frontend_roots}} (empty = none).
+      Where that is non-empty, EXCLUDE those roots when deriving the structure — the lane has
+      its own design template pair, generated next, and one lane's template must never describe
+      the other's code. A UI tier that is NOT a separable lane (rendered inside the service
+      tree) stays here as one of this project's own structural axes.
+
+      Identify the RECURRING structural convention across features (the real layer/tier/module
+      folders + the dependency rule) from evidence 1–3 — this ONE template governs every
+      future feature.
+
+      Then AUTHOR the template on the skeleton's §0–§6 shape (the shape the forward `design`
+      brownfield branch expects — keep these section numbers + headings):
+      - Keep the skeleton's header block (Aggregate / Design home / Source spec / Version /
+        Status) and its TECHNOLOGY-AGNOSTIC authoring rules (behaviour as signatures +
+        pre/post/invariant/raises, contracts as field shapes, NO code; every element traces to
+        a spec id). Fill [GENERATED_STRUCTURE_NOTE] with this project's convention.
+      - §0 Design Overview + `### Ubiquitous Language (design delta)` — carry over as-is.
+      - §1 Architecture Context & Domain Model:
+          §1.1 As-Built Architecture — describe THIS project's real structural convention you
+            discovered FROM THE CODE + the technical constitution (name the actual layer/tier/
+            module folders with representative code paths, the dependency direction, the tech
+            base). A new feature ALIGNS to this.
+          §1.2 Domain / Data Model — PINNED ANCHOR, carry the skeleton's guidance over
+            unchanged (entities & value objects = spec Key Entities; invariants = spec BR-nnn;
+            aggregate boundary; lifecycle/states; cross-slice references-by-id). aw-xref reads
+            this section for reference edges, so it keeps its position.
+      - §2 Component & Behaviour Design — ONE `### 2.n` subsection PER RECURRING STRUCTURAL
+        AXIS the project actually uses, each TITLED after the project's OWN folder/tier name.
+        The count and the titles are the code's answer; the skeleton's slots are positions, not
+        a set to fill. In each, template the components that live there + their behaviour in
+        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.
+      - §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.
+      - §4 Traceability — carry the skeleton's spine over (every FR/BR/CN/DC/IC/US/SC has a
+        design home; the Section column uses the project's OWN section refs).
+      - §5 Assumptions (DA-n) — carry over, "None (as of vX.Y)".
+      - §6 Deviations / Deferred Decisions (WA-n) — carry over, AS-BUILT: it records genuine
+        deviations, NOT "organised unlike a reference architecture" (that is the as-built
+        shape, §1.1).
+      - Change History — carry over.
+      Keep every [PLACEHOLDER] and authoring comment so `design` can fill it — and in those
+      comments DIRECT the downstream author (forward `design` / adopt) to GROUND each filled
+      section in the ACTUAL CODE + the reverse-engineered files (cite real file/folder paths and
+      the relevant technical-constitution principle). Do NOT invent project structure the code
+      does not show; where the convention is unclear, template a generic axis and flag it in a
+      comment. Write ONLY the override file; modify no source.
+      Report the file written + the structural axes you derived (with the code paths that
+      evidence them).
+    outputs:
+      - { name: design_template_files, from: "$.files" }
+
+  - id: verify_design_template
+    action: verify_context
+    condition: "{{svc_lane}} == true"
+    require_non_empty: design_template_files
+    on_empty: stop
+    on_empty_message: "No design template was written to .appweaver/templates/overrides/design-template.md. Ensure the scan substrate (inventory_json) + the technical constitution are present and re-run."
+
+  # DELTA-DESIGN template — MIRROR the just-generated master template's OWN sections so a
+  # change classifies ADDED/MODIFIED/REMOVED against the code-derived structure, not the
+  # greenfield four layers. Aligns with the delta-design module (classifies "per the
+  # master's OWN section structure").
+  - id: ctx_delta_design_template
+    action: build_context
+    condition: "{{svc_lane}} == true"
+    context:
+      - { path: .appweaver/templates/overrides/design-template.md, optional: true }      # PRIMARY: the JUST-generated code-derived master — mirror its ACTUAL sections
+      - { path: .appweaver/orchestrator/rev-templates/delta-design-template.skeleton.md } # SHAPE ONLY: the neutral change-record bones (zero layering, zero technology)
+      - { path: "{{constitution_technical_file}}" }                                    # the validated as-built technology base (keep the delta consistent with the master)
+  - id: gen_delta_design_template
+    action: agent_generate
+    condition: "{{svc_lane}} == true"
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      Author the matching PROJECT-SPECIFIC DELTA-design TEMPLATE and Write it to
+      .appweaver/templates/overrides/delta-design-template.md. It is a TEMPLATE (placeholders
+      + authoring comments) for classifying a CHANGE to a feature as ADDED / MODIFIED /
+      REMOVED against the master design.md.
+
+      MIRROR the just-generated master template (.appweaver/templates/overrides/design-template.md,
+      in context — Read it): its ADDED/MODIFIED/REMOVED tables must key off the master's OWN
+      code-derived sections (§1.1/§1.2, the §2.n axes it derived, §3). Use the skeleton's
+      "Section (§ in design.md)" column and fill its example rows with the ACTUAL sections of
+      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 close. 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-design module, which classifies "per the master's OWN
+        section structure" — so the template MUST NOT hardcode a fixed layering.
+      Keep every [PLACEHOLDER] and authoring comment. Write ONLY the override file; modify no
+      source. Report the file written.
+    outputs:
+      - { name: delta_design_template_files, from: "$.files" }
+
+  - id: verify_delta_design_template
+    action: verify_context
+    condition: "{{svc_lane}} == true"
+    require_non_empty: delta_design_template_files
+    on_empty: stop
+    on_empty_message: "No delta-design template was written to .appweaver/templates/overrides/delta-design-template.md. Re-run onboard after confirming the design template override was generated."
+
+  # ═══════ UI DESIGN TEMPLATES (frontend lane only) — the LANE's own pair ═══════
+  # The lane's twin of the two steps above, on the same terms: reverse-engineered from
+  # the UI SOURCE, shaped by a NEUTRAL skeleton, installed in the project override slot
+  # (.appweaver/templates/overrides/{ui-design,ui-delta-design}-template.md). Written ONLY
+  # where the scan found a lane, so a backend-only repo gets neither file — the same
+  # "absence is meaningful" property constitution.ui.md has.
+  #
+  # WHY THE LANE NEEDS ITS OWN PAIR rather than a section inside the service design: the
+  # two lanes are governed by different constitution halves and different map headings,
+  # they are implemented by different commands, and the ONLY thing that crosses between
+  # them is the design contract. A UI section inside design.md would put the lane's
+  # structure under the service lane's rules and hand ⌛ ui-design the whole service
+  # design to read — precisely the context leak the contract projection exists to stop.
+  #
+  # THE SECTION LIST IS RATIFIED, THE CONTENT IS THE CODE'S. aw-spec specifies what
+  # design.ui.md contains (navigation & screen structure · client state · component
+  # structure · interaction & flow · contract binding · cross-cutting · traceability ·
+  # DA-n · WA-n); the skeleton carries exactly that, framework-free. What this step
+  # derives from the lane's source is what goes IN those sections — the real composition
+  # axes, the state and styling conventions, the screen vocabulary.
+  #
+  # THE CONSUMERS ARE ⌛ NOT BUILT (B-14 / B-15: ui-design, ui-implement, the three-master
+  # merge in finalize-delta). The templates are written now anyway, and deliberately: the
+  # evidence for them is the whole-repo vantage that exists exactly once, at onboard, and
+  # resolve_template finds them by name the day those commands land. Nothing reads them
+  # before then, and nothing breaks for their absence in a repo that never onboarded.
+  - id: ctx_ui_design_template
+    action: build_context
+    condition: "{{ui_lane}} == true"
+    context:
+      - { path: "{{inventory_json}}" }                                                     # PRIMARY: the COMPLETE deterministic substrate — frontend_signals + the component/route/store/style file lists to read source from
+      - { path: "{{constitution_ui_file}}" }                                               # PRIMARY: the VALIDATED as-built UX-* base — the ratified principles this structure must serve
+      - { path: .appweaver/orchestrator/rev-templates/ui-design-template.skeleton.md }       # SHAPE ONLY: the ratified section list + neutral bones (zero framework, zero component library)
+      - { path: "{{pack_dir}}/frontend/ui-constitution.md", optional: true }               # the generated lane rule set's base file — the detail layer under those principles
+      - { path: "{{bundle_dir}}/architecture/frontend.md", optional: true }                # SECONDARY (shallow): the OKF as-built frontend note
+  - id: gen_ui_design_template
+    action: agent_generate
+    condition: "{{ui_lane}} == true"
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      REVERSE-ENGINEER this repo's FRONTEND LANE into a PROJECT-SPECIFIC UI DESIGN TEMPLATE
+      and Write it to .appweaver/templates/overrides/ui-design-template.md (create the
+      overrides/ dir if absent). It is a TEMPLATE — concrete lane-derived section content
+      with [PLACEHOLDER] tokens + authoring HTML comments that ⌛ `ui-design` fills per
+      feature into specs/<Feature>/design.ui.md — NOT a filled design.
+      The lane: {{ui_evidence}} · roots: {{frontend_roots}}
+
+      GROUND EVERYTHING IN THE LANE'S OWN CODE. Evidence authority, in order:
+        1. THE ACTUAL UI SOURCE (ground truth). Use {{inventory_json}} (in context):
+           `frontend_signals` gives the lane roots, their kind (spa / server-rendered /
+           desktop), their framework markers and their component / route / store / style
+           file lists. READ ENOUGH OF THOSE FILES to state each structural claim from what
+           the UI ACTUALLY does. Do NOT assert a convention you have not seen.
+        2. constitution.ui.md (in context) — the VALIDATED as-built UX-* base. The template's
+           authoring comments point the downstream author at the UX principle each section
+           serves; cite them by their real numerals.
+        3. The generated frontend/ui-constitution.md and the OKF architecture/frontend.md
+           (in context, if present) — the lane's own rule detail and a shallow corroboration.
+      STAY INSIDE THE LANE. Derive structure ONLY from code under the lane's roots. The
+      service lane has its own template, generated just above; this one never describes
+      server-side structure.
+
+      THE SKELETON IS SHAPE ONLY. rev-templates/ui-design-template.skeleton.md (in context)
+      carries the ratified section list, the neutral bones and the authoring rules — and
+      names NO framework, router, state library, component library, design system or styling
+      approach. That omission is deliberate and you MUST preserve it: the generated template
+      stays technology-agnostic even though you derived it from a real stack, because the
+      framework binds later at ⌛ `ui-implement` from constitution.ui.md plus that command's
+      rule set. Describe a component by its RESPONSIBILITY, its INPUTS as field shapes, the
+      EVENTS it raises and the STATES it can be in — never by a framework's own vocabulary.
+
+      Identify the RECURRING composition convention across the lane's screens (how screens
+      are organised and named, what is shared, where client state lives, how server data is
+      fetched and invalidated, how styling is applied) — this ONE template governs every
+      future feature's UI.
+
+      Then AUTHOR the template on the skeleton's shape, keeping its section numbers and
+      headings:
+      - Keep the header block and the TECHNOLOGY-AGNOSTIC authoring rules. Fill
+        [GENERATED_LANE_STRUCTURE_NOTE] and §0's `### As-Built Lane Structure` with this
+        lane's real convention, each claim carrying a representative path. Where the UI is
+        rendered inside the service tree and owns no root of its own, say exactly that.
+      - §1 Navigation & Screen Structure — template the screen inventory and the navigation
+        shape THIS lane uses, described conceptually (a path pattern, a stack, a tab set),
+        read from the routing code and never named after a router.
+      - §2 Client State — template the state kinds this lane actually holds and the
+        invalidation triggers it actually uses. If the lane holds no client state beyond
+        form fields, say so as-built rather than templating a store it does not have.
+      - §3 Component Structure — ONE `### 3.n` subsection PER RECURRING COMPOSITION AXIS the
+        lane uses, each TITLED with the lane's OWN name for it. The count and titles are the
+        code's answer; the skeleton's slots are positions, not a set to fill.
+      - §4 Interaction & Flow and §6 Cross-Cutting — KEEP BOTH, always, even where this lane
+        shows little. They are the two sections a backend-shaped process drops and where
+        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 reads the
+        ⌛ design-contract projection, never the service design. Note in the authoring
+        comment that where no contract document exists 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
+        over; the §7 Section column uses THIS template's own section refs.
+      Keep every [PLACEHOLDER] and authoring comment so ⌛ `ui-design` can fill it — and in
+      those comments DIRECT the downstream author to GROUND each filled section in the
+      ACTUAL UI CODE and the lane's governance (cite real component/route/store/stylesheet
+      paths and the constitution.ui.md UX numeral). Do NOT invent lane structure the code
+      does not show; where the convention is inconsistent, template the DOMINANT form and
+      flag the divergence in a comment. Write ONLY the override file; modify no source.
+      Report the file written + the composition axes you derived (with the code paths that
+      evidence them).
+    outputs:
+      - { name: ui_design_template_files, from: "$.files" }
+
+  - id: verify_ui_design_template
+    action: verify_context
+    condition: "{{ui_lane}} == true"
+    require_non_empty: ui_design_template_files
+    on_empty: stop
+    on_empty_message: "A frontend lane was detected ({{ui_evidence}}) but no UI design template was written to .appweaver/templates/overrides/ui-design-template.md. Check that the scan substrate's frontend_signals carry readable UI source, then re-run."
+
+  # UI DELTA-DESIGN template — MIRROR the just-generated UI master's OWN sections, exactly
+  # as the service delta mirrors the service master.
+  - id: ctx_ui_delta_design_template
+    action: build_context
+    condition: "{{ui_lane}} == true"
+    context:
+      - { path: .appweaver/templates/overrides/ui-design-template.md, optional: true }            # PRIMARY: the JUST-generated lane master — mirror its ACTUAL sections
+      - { path: .appweaver/orchestrator/rev-templates/ui-delta-design-template.skeleton.md }      # SHAPE ONLY: the neutral change-record bones (zero framework)
+      - { path: "{{constitution_ui_file}}" }                                                    # the validated UX-* base (keep the delta consistent with the master)
+  - id: gen_ui_delta_design_template
+    action: agent_generate
+    condition: "{{ui_lane}} == true"
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      Author the matching PROJECT-SPECIFIC UI DELTA-design TEMPLATE and Write it to
+      .appweaver/templates/overrides/ui-delta-design-template.md. It is a TEMPLATE
+      (placeholders + authoring comments) for classifying a CHANGE to a feature's
+      EXPERIENCE as ADDED / MODIFIED / REMOVED against the master design.ui.md.
+
+      MIRROR the just-generated lane master (.appweaver/templates/overrides/ui-design-template.md,
+      in context — Read it): its ADDED/MODIFIED/REMOVED tables must key off that master's OWN
+      sections, including whatever composition axes its §3 derived. Use the skeleton's
+      "Section (§ in design.ui.md)" column and fill its example rows with the ACTUAL sections
+      of the generated master. Never name a framework or a UI taxonomy the master did not
+      derive.
+      - 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 close.
+      - 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.
+      - KEEP the lane boundary: contract impact is raised BACK to the service lane, never
+        worked around in the client.
+      - A shared component or state container is MODIFIED in place, never duplicated into the
+        change; every changed element serves a spec id; behaviour stays technology-agnostic
+        (responsibilities, field shapes, events — no code).
+      Keep every [PLACEHOLDER] and authoring comment. Write ONLY the override file; modify no
+      source. Report the file written.
+    outputs:
+      - { name: ui_delta_design_template_files, from: "$.files" }
+
+  - id: verify_ui_delta_design_template
+    action: verify_context
+    condition: "{{ui_lane}} == true"
+    require_non_empty: ui_delta_design_template_files
+    on_empty: stop
+    on_empty_message: "No UI delta-design template was written to .appweaver/templates/overrides/ui-delta-design-template.md. Re-run onboard after confirming the UI design template override was generated."
+
+  # Post-execution hooks.
+  - id: resolve_post_hooks
+    action: execute_script
+    script: { ref: actions }
+    subcommand: resolve-hooks
+    args: ["--phase", "after_onboard"]
+    outputs:
+      - { name: after_hooks, from: "$.hooks" }
+  - id: dispatch_post_hooks
+    action: dispatch_hooks
+    hooks_from_variable: after_hooks
+
+outputs:
+  bundle_dir: "{{bundle_dir}}"
+  aggregate_count: "{{aggregate_count}}"
+  concepts: "{{concepts}}"
+  warnings: "{{okf_warnings}}"
+  domain_slug: "{{domain_slug}}"
+  pack_dir: "{{pack_dir}}"
+  domain_rule_bindings: "{{domain_rule_bindings}}"
+  tech_rule_bindings: "{{pack_dir}}/tech-rule-bindings.md"
+  pack_files: "{{pack_files}}"
+  tech_pack_files: "{{tech_pack_files}}"
+  ui_pack_files: "{{ui_pack_files}}"
+  domain_constitution_source: "{{domain_constitution_source}}"
+  constitution_technical_file: "{{constitution_technical_file}}"
+  constitution_domain_file: "{{constitution_domain_file}}"
+  constitution_ui_file: "{{constitution_ui_file}}"
+  composed_file: "{{composed_file}}"
+  active_domain: "{{active_domain}}"
+  # The lanes this run was told to govern, and what their source turned out to hold.
+  service_lane: "{{svc_lane}}"
+  ui_lane: "{{ui_lane}}"
+  ui_lane_evidence: "{{ui_evidence}}"
+  ui_lane_declaration: "{{ui_declaration_note}}"
+  ui_source_evidence_found: "{{ui_evidence_found}}"
+  ui_included: "{{ui_included}}"
+  ui_validation_ok: "{{ui_validation_state}}"
+  frontend_roots: "{{frontend_roots}}"
+  # The lane declaration this run READ. select-stack wrote it; onboard never touches it.
+  stacks_file: "{{stacks_file}}"
+  backend_lane: "{{be_lane_id}} ({{be_profile}}) at {{be_root}}"
+  frontend_lane: "{{fe_lane_id}} ({{fe_profile}}) at {{fe_root}}"
+  # What the scan was scoped to, and how many files each lane's substrate was built
+  # from. Backend signals exclude the UI subtree; frontend signals are that subtree.
+  scanned_service_root: "{{scoped_service_root}}"
+  scanned_ui_root: "{{scoped_ui_root}}"
+  scanned_backend_files: "{{backend_file_count}}"
+  scanned_ui_files: "{{frontend_file_count}}"
+  design_template_override: ".appweaver/templates/overrides/design-template.md"
+  delta_design_template_override: ".appweaver/templates/overrides/delta-design-template.md"
+  design_template_files: "{{design_template_files}}"
+  delta_design_template_files: "{{delta_design_template_files}}"
+  # The lane's own template pair. Empty on a backend-only repo — no lane, no files.
+  ui_design_template_files: "{{ui_design_template_files}}"
+  ui_delta_design_template_files: "{{ui_delta_design_template_files}}"
+  technical_validation_ok: "{{technical_ok}}"
+  domain_validation_ok: "{{domain_ok}}"
+  next: "Onboarded {{project_name}}: a high-level feature map at {{bundle_dir}} + a PROVISIONAL project governance scaffold, domain {{active_domain}} ACTIVATED, and — reverse-engineered from THIS code alone — the rule tiers wired per-workflow: the DOMAIN set (guardrails/projects/{{domain_slug}}/domain/*.domain.md + domain-rule-bindings.md) always, and each LANE's set where that lane is declared. ONE HALF AND ONE RULE SET PER LANE: service_lane / ui_lane report which lanes .appweaver/stacks.json declared, and the declaration is what decided. A declared service lane gets constitution.technical.md, guardrails/projects/{{domain_slug}}/service/*.md + tech-rule-bindings.md, and the service design/delta-design template overrides; a declared UI lane gets constitution.ui.md, guardrails/projects/{{domain_slug}}/frontend/*.md mapped under ## /aw-spec-ui-constitution, and its own template pair. A lane declared (none) in select-stack gets none of it, which is the correct outcome and not an omission. LANE DECLARATION: read, never written — select-stack is its sole writer, and this run scanned the source paths it named (scanned_service_root / scanned_ui_root). The scan was SCOPED by them, so the backend substrate excludes the UI subtree and the frontend substrate is that subtree: scanned_backend_files / scanned_ui_files report each. ui_source_evidence_found false means the UI lane's declared path held nothing a scan recognises as UI, so its governance is thin — move the source path with /appweaver select-stack and re-run. The build/test/run commands on each lane are that PROFILE's defaults and may not match a legacy layout — review them, and re-run /appweaver select-stack to correct any lane. Because the domain is activated, resolve-domain + resolve-tech now route the WHOLE forward pipeline AND adopt to these code-derived rules — never another project's rules as a fallback. Code-derived design + delta-design templates are installed as the project template overrides (.appweaver/templates/overrides/) so a NEW feature is developed against the as-built architecture with NO adopt — every section derived from a NEUTRAL skeleton plus this repo's own structure, with no greenfield template in context. Where the lane exists, the SAME pair is generated for it (ui-design-template.md + ui-delta-design-template.md) from the UI source; ui-design-template.md is consumed by /appweaver adopt, which reverses a slice's design.ui.md from it wherever that slice owns part of the lane's surface; ui-delta-design-template.md still waits, since ui-design / ui-implement are not built yet. Develop an EXISTING feature just-in-time: /appweaver adopt <Feature> reverse-engineers its spec.md + design.md + source-map.md and completes that feature's OKF concept; its governance reconcile is currently HELD, so the scaffold this run wrote stays as it is. Develop a NEW feature straight through the forward pipeline (/appweaver specify → design → implement). Then drive every change through the CR delta loop (/appweaver specify → design → analyze-delta-design → implement-delta → build → finalize-delta → analyze-slice → close-delta). If a validation_ok is false, its constitution half needs a manual touch (see its Sync Impact Report)."