aw-spec-cli 0.1.3 → 0.1.5

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

@@ -0,0 +1,949 @@
+# =============================================================================
+# 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 /aw-spec-orch 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 docs/domainspecs/
+#      brf-<domain>/ rule-file pack (+ comandrulemap), the domain-constitution
+#      source, 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.
+#
+# CODE-DERIVED RULE PACKS + MAPS (both tiers): onboard authors, from the code ALONE
+# (never a greenfield rule file), BOTH the DOMAIN rule-file pack (*.domain.md +
+# comandrulemap.md) AND the TECHNICAL rule-file pack (docs/domainspecs/brf-<domain>/tech/*.md
+# + commandtechrulemap.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
+# greenfield docs/architecture / docs/security file. Both packs 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 pack carries ONE file for /specify — tech/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 greenfield's docs/domain/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 pack (domain-driven-design.domain.md); HOW to model lives here.
+#
+# Never modifies source — every write lands in the OKF bundle, the specs governance dir,
+# docs/domainspecs/ (domain pack + tech/ pack + both maps), or the
+# .aw-spec/templates/overrides/ design templates.
+#
+# Launch:  /aw-spec-orch onboard [domain-name / scope hint] [; concerns: a, b, c]
+#   e.g.   /aw-spec-orch onboard Pharma
+#   e.g.   /aw-spec-orch 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 + docs/domainspecs/brf-<domain>/ DOMAIN rule-file pack + comandrulemap + a code-derived TECHNICAL rule-file pack at brf-<domain>/tech/ + commandtechrulemap + activated domain), all provisional-from-scan and refined per slice by adopt. Both rule tiers are 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. Accepts an optional concerns list to look for (onboard decides which are actually present). No migration content; never modifies source.
+version: 1.3.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 pack
+      (e.g. Pharma → docs/domainspecs/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-pack 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:  .aw-spec/scripts/bash/aw-inventory.sh
+    ps1: .aw-spec/scripts/powershell/aw-inventory.ps1
+  revcon:
+    sh:  .aw-spec/scripts/bash/aw-rev-constitution.sh
+    ps1: .aw-spec/scripts/powershell/aw-rev-constitution.ps1
+  actions:
+    sh:  .aw-spec/scripts/bash/aw-spec-actions.sh
+    ps1: .aw-spec/scripts/powershell/aw-spec-actions.ps1
+
+# NO sticky standards. agent_generate ALWAYS injects the standards set (it cannot opt
+# out), so an empty set guarantees no governance skeleton or greenfield exemplar 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: []
+
+vars:
+  bundle_present: "false"   # inventory bundle_guard driver
+  conformant:     "false"   # OKF conformance-gate driver
+  pack_present:   "false"   # domain-pack anti-clobber driver
+  technical_ok:   "false"   # technical-half lint guard
+  domain_ok:      "false"   # domain-half lint guard
+
+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).
+
+  # 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.
+  - id: scan
+    action: execute_script
+    script: { ref: inventory }
+    subcommand: scan
+    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" }
+
+  # 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 /aw-spec-orch 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."
+
+  # 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: .aw-spec/templates/okf-concept-template.md }  # OKF v0.1 format authority (frontmatter, index, log, rules)
+      - { path: docs/domain/domain-driven-design.md, optional: true }  # OPTIONAL: aggregate/entity/VO/event vocabulary for naming only
+  - 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 /aw-spec-orch 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; `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 DbContext, 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.
+
+      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 (DbContext, 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.
+      - `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.
+      - `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.0.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 docs/domainspecs/brf-<domain>/.
+  # Name: explicit arg → PROJECT name from the OKF overview → repo basename. Guarded
+  # against clobbering a pack that already holds .md files.
+  - id: pack_setup
+    action: execute_script
+    script: { ref: revcon }
+    subcommand: pack-setup
+    args: ["--name", "{{USER_INPUT}}", "--fallback", "{{project_name}}"]
+    outputs:
+      - { name: domain_slug,                from: "$.domain_slug" }
+      - { name: pack_dir,                   from: "$.pack_dir" }
+      - { name: comandrulemap,              from: "$.comandrulemap" }
+      - { 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 domain pack docs/domainspecs/{{domain_slug}}/ already holds curated rule files — onboard would overwrite them. Back up or remove that folder to re-onboard, or amend it via /aw-spec-orch constitution."
+
+  # ── DOMAIN RULE-FILE PACK (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: .aw-spec/orchestrator/rev-templates/comandrulemap.skeleton.md, optional: true }
+      - { path: .aw-spec/orchestrator/rev-templates/domain-rule-file.skeleton.md, optional: true }
+      - { path: .aw-spec/orchestrator/rev-templates/domain-requirements.skeleton.md, optional: true }
+      - { path: .aw-spec/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-FILE PACK for **{{project_name}}** (domain
+      {{domain_slug}}) into docs/domainspecs/{{domain_slug}}/ (the dir exists).
+
+      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. Consider, include only if evidenced:
+        - domain-driven-design.domain.md  — the ubiquitous language + bounded-context /
+          feature map (almost always evidenced; the modelling standard 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.0.0`,
+      and note the pack is a provisional scaffold reconciled per slice at adopt.
+
+      comandrulemap.md (MANDATORY — /specify's resolve-domain reads this exact filename).
+      Wire ONLY the files you generated, preserving the RULE PARTITION:
+        - `## /aw-spec-constitution` — 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 `- docs/domainspecs/{{domain_slug}}/<file>`.
+      Write ONLY inside docs/domainspecs/{{domain_slug}}/. 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 docs/domainspecs/{{domain_slug}}/. Ensure the feature map carries a modellable domain (a feature map + ubiquitous language) and re-run."
+  - id: require_comandrulemap
+    action: verify_context
+    required_files: ["{{comandrulemap}}"]
+
+  # ── DOMAIN CONSTITUTION SOURCE — docs/brf-<domain>-constitution.md ───────────
+  - id: ctx_domain_source
+    action: build_context
+    context:
+      - { path: "{{comandrulemap}}" }
+      - { path: .aw-spec/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 pack's comandrulemap.md. Follow the SHAPE of the
+      neutral skeleton domain-constitution.skeleton.md (in context) — its Project-Identity
+      + Domain-Principle structure — so the normal /aw-spec-orch 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 pack's rule files.
+      Return the charter markdown only.
+
+  # ── SPLIT CONSTITUTION — scaffold the two memory halves ──────────────────────
+  - id: setup_constitution
+    action: execute_script
+    script: { ref: actions }
+    subcommand: setup-constitution
+    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
+    context:
+      - { path: "{{constitution_technical_file}}" }
+      - { path: .aw-spec/orchestrator/rev-templates/technical-constitution.skeleton.md, optional: true }
+      - { path: .aw-spec/orchestrator/rev-templates/ai-rules.reference.md, optional: true }
+    context_from: design_context
+  - id: author_technical
+    action: agent_author
+    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
+    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.
+
+  # DOMAIN HALF — from the pack + 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: "{{comandrulemap}}" }
+    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 pack (comandrulemap in context; READ
+      the pack's rule files under docs/domainspecs/{{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 placeholder; NO residual [BRACKET] may remain (it blocks composition).
+      - Author ONLY the domain layer: domain principles, domain folder additions,
+        regulatory/security posture, domain governance — from the pack + 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" }
+
+  # Auto-activate: point .aw-spec/domain.json at the scaffolded pack 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-FILE PACK (code-derived) — the technical twin of the ═══
+  #            domain pack 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. docs/domainspecs/<domain>/tech/<concern>.md — evidenced-only code-derived tech rule
+  #      files (the docs/architecture · docs/security · docs/governance ANALOG, but reverse-
+  #      engineered from THIS code, never a greenfield file), INCLUDING the one file that
+  #      feeds /specify: tech/domain-modelling.md, the as-built modelling METHODOLOGY (the
+  #      analog of greenfield docs/domain/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. docs/domainspecs/<domain>/commandtechrulemap.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 — no greenfield docs/architecture fallback, ever. The pack
+  # lives inside pack_dir, so pack_guard (above) already protects it from clobber.
+  - id: ctx_tech_pack
+    action: build_context
+    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: .aw-spec/orchestrator/rev-templates/commandtechrulemap.skeleton.md, optional: true }   # SHAPE ONLY: the technical map's headings + partition + table (zero real files)
+      - { path: .aw-spec/orchestrator/rev-templates/technical-rule-file.skeleton.md, optional: true }  # SHAPE ONLY: one code-derived tech rule file's shape (zero real tech)
+      - { path: .aw-spec/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
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      Scaffold the PROJECT-level TECHNICAL RULE-FILE PACK for **{{project_name}}** (domain
+      {{domain_slug}}) — the CODE-DERIVED replacement for the greenfield technical rule set —
+      into docs/domainspecs/{{domain_slug}}/tech/ (create it), plus the technical map
+      docs/domainspecs/{{domain_slug}}/commandtechrulemap.md. This is the TECHNICAL twin of the
+      already-generated domain pack: 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 greenfield rule file (docs/architecture/*,
+      docs/security/*, docs/governance/*, docs/interop/*, docs/VerticalSlice/*) — those are the
+      greenfield fixture, NOT this project's rules. Every path you write lives under
+      docs/domainspecs/{{domain_slug}}/tech/.
+
+      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 `tech/<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.3.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 — `tech/domain-modelling.md` (concern: domain-modelling). This is the
+      ONE file in this pack 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
+      pack's domain-driven-design.domain.md, 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).
+
+      commandtechrulemap.md (MANDATORY — resolve-tech + the tech-select module read this exact
+      filename). Follow the SHAPE of commandtechrulemap.skeleton.md (in context) and the rule
+      partition (.aw-spec/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: `tech/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-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 `- docs/domainspecs/{{domain_slug}}/tech/<file>`. Close with the
+      quick-reference table. Write ONLY inside docs/domainspecs/{{domain_slug}}/ (tech/ + 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
+    require_non_empty: tech_pack_files
+    on_empty: stop
+    on_empty_message: "No technical rule files were written to docs/domainspecs/{{domain_slug}}/tech/. Ensure the scan substrate (inventory_json) + the validated technical constitution carry an as-built technology base and re-run."
+  - id: require_commandtechrulemap
+    action: verify_context
+    required_files: ["{{pack_dir}}/commandtechrulemap.md"]
+
+  # ═══════════ 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
+  # (.aw-spec/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. The
+  # greenfield template supplies ONLY the NON-architectural bones (overview, the §1.2 domain/
+  # data-model anchor, the traceability spine, the Assumptions/Deviations ledgers, Change
+  # History) + the tech-agnostic authoring rules; its four greenfield layers MUST NOT leak —
+  # the ARCHITECTURAL sections come from the code only. The generated skeleton keeps the §0–§6
+  # shape the forward `design` bootstrap_bf branch expects, so no workflow change is needed to
+  # consume it. Re-onboard is gated upstream (bundle_guard / pack_guard) — remove the OKF
+  # bundle to regenerate.
+
+  # DESIGN template — feed the code-derived evidence (code + inventory + technical
+  # constitution) FIRST, the greenfield template for NEUTRAL bones only, then AUTHOR the override.
+  - id: ctx_design_template
+    action: build_context
+    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: .aw-spec/templates/design-template.md }                       # SHAPE ONLY: the greenfield template — NEUTRAL bones to carry over + tech-agnostic authoring rules (its four layers must NOT leak)
+      - { 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
+    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 .aw-spec/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 greenfield
+      template and NOT the shallow OKF map. 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 greenfield .aw-spec/templates/design-template.md is a SHAPE reference for the NEUTRAL
+      sections + the tech-agnostic authoring rules ONLY — its Domain/Application/API/
+      Infrastructure layering MUST NOT appear in the derived §1.1/§2.
+
+      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 with this §0–§6 skeleton (the shape the forward `design`
+      brownfield branch expects — keep these section numbers + headings):
+      - Keep the greenfield template'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).
+      - §0 Design Overview + `### Ubiquitous Language (design delta)` — CARRY OVER (neutral).
+      - §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 — NEUTRAL ANCHOR: carry over the greenfield §1 domain-model
+            guidance (entities & value objects = spec Key Entities; invariants = spec BR-nnn;
+            aggregate boundary; lifecycle/states; cross-slice references-by-id).
+      - §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
+        (NOT a fixed Domain/Application/API/Infrastructure layering). In each, template the
+        components that live there + their behaviour in signature form + the ports/contracts.
+        Include exactly one subsection whose heading contains the word "Integration" (the
+        External Integrations table — one port/adapter row per IC-) as a pinned anchor.
+      - §3 Cross-Cutting Concerns — carry over the greenfield §5 table (security, data
+        protection, audit, observability, performance, retention, idempotency/concurrency;
+        Serves = a spec id or a §5 DA-n).
+      - §4 Traceability — CARRY OVER the greenfield §6 spine (every FR/BR/CN/DC/IC/US/SC has a
+        design home; the Layer column uses the project's OWN section refs).
+      - §5 Assumptions (DA-n) — carry over the greenfield §7 ledger, "None (as of vX.Y)".
+      - §6 Deviations / Deferred Decisions (WA-n) — carry over the greenfield §8 ledger, but
+        frame it 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), NEVER a greenfield assumption. 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
+    require_non_empty: design_template_files
+    on_empty: stop
+    on_empty_message: "No design template was written to .aw-spec/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
+    context:
+      - { path: .aw-spec/templates/overrides/design-template.md, optional: true }      # PRIMARY: the JUST-generated code-derived master — mirror its ACTUAL sections
+      - { path: .aw-spec/templates/delta-design-template.md }                          # SHAPE ONLY: greenfield delta template — NEUTRAL bones to carry over
+      - { 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
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      Author the matching PROJECT-SPECIFIC DELTA-design TEMPLATE and Write it to
+      .aw-spec/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 (.aw-spec/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), NOT the greenfield four
+      layers (Domain/Application/API/Infra). Use a "Section (§ in design.md)" column whose
+      example rows name the ACTUAL sections of the generated master template.
+      - CARRY OVER the greenfield delta template's neutral parts (in context): Change summary,
+        Cross-section impact, Regression targets, New assumptions/workarounds (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
+    require_non_empty: delta_design_template_files
+    on_empty: stop
+    on_empty_message: "No delta-design template was written to .aw-spec/templates/overrides/delta-design-template.md. Re-run onboard after confirming the 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}}"
+  comandrulemap: "{{comandrulemap}}"
+  commandtechrulemap: "{{pack_dir}}/commandtechrulemap.md"
+  pack_files: "{{pack_files}}"
+  tech_pack_files: "{{tech_pack_files}}"
+  domain_constitution_source: "{{domain_constitution_source}}"
+  constitution_technical_file: "{{constitution_technical_file}}"
+  constitution_domain_file: "{{constitution_domain_file}}"
+  composed_file: "{{composed_file}}"
+  active_domain: "{{active_domain}}"
+  design_template_override: ".aw-spec/templates/overrides/design-template.md"
+  delta_design_template_override: ".aw-spec/templates/overrides/delta-design-template.md"
+  design_template_files: "{{design_template_files}}"
+  delta_design_template_files: "{{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 (constitution.technical.md + constitution.domain.md), domain {{active_domain}} ACTIVATED, and — reverse-engineered from THIS code alone — BOTH rule tiers wired per-workflow: the DOMAIN pack (docs/domainspecs/{{domain_slug}}/*.domain.md + comandrulemap.md) AND the TECHNICAL pack (docs/domainspecs/{{domain_slug}}/tech/*.md + commandtechrulemap.md). Because the domain is activated, resolve-domain + resolve-tech now route the WHOLE forward pipeline AND adopt to these code-derived rules — no greenfield docs/architecture / docs/security fallback. Code-derived design + delta-design templates are installed as the project template overrides (.aw-spec/templates/overrides/) so a NEW feature is developed against the as-built architecture with NO adopt. Develop an EXISTING feature just-in-time: /aw-spec-orch adopt <Feature> reverse-engineers its spec.md + design.md and RECONCILES the governance with the slice's evidence. Develop a NEW feature straight through the forward pipeline (/aw-spec-orch specify → design → implement). Then drive every change through the CR delta loop (/aw-spec-orch 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)."