aw-spec-cli 0.1.15 → 0.1.17

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

@@ -1,540 +0,0 @@
-# =============================================================================
-# aw-spec-implement-ui (orchestrator) — UI generation from ONE STORY'S DESIGN
-#
-# The frontend lane's executable end of the story loop: GENERATE the screens,
-# components, client state and paired tests for ONE STORY, strictly from the LATEST
-# design pass in that story's own UI design —
-# specs/<F>/stories/<ID>/story-frontend-plan.md. It is the twin of `implement`, one
-# lane over, and keeps the same contract:
-#
-#   • ONE SLICE, NOT THE FEATURE. The pass names the files it changes; this phase edits
-#     an existing tree, creating only what the pass says is new, and MERGES its files
-#     into the feature's OKF concept rather than replacing the list.
-#   • DESIGN-ONLY. spec.md is not a generation input. It is read once, AFTER the code
-#     exists, by a read-only acceptance check that reports and never repairs.
-#   • THE FRAMEWORK BINDS HERE. The design is technology-agnostic — a "component" is a
-#     responsibility, its inputs are field shapes, its states are named. The framework,
-#     router, state library, component library and styling approach come from
-#     constitution.ui.md + the lane declaration + this command's rule set.
-#   • ONE SUBTREE. The lane owns the source path .appweaver/stacks.json declares for it
-#     and nothing outside it. A file written elsewhere belongs to the service lane.
-#
-# THE UI LANE CONSUMES THE CONTRACT; IT NEVER DEFINES ONE. interfaces.md is the
-# published surface and the pass binds to it by IF- id. A contract this slice needs that
-# the log does not carry is a DEFECT to surface — never an endpoint to invent, and never
-# a reason to reach into the service lane's code. Where the SAME story has a service
-# design it is in context too, as the newer word on what that surface will be.
-#
-# WHY A SEPARATE COMMAND, NOT A UI BRANCH INSIDE `implement`. The two lanes take their
-# code-generation rules from different map headings and write into disjoint subtrees.
-# Keying the rule maps on `## /aw-spec-implement-ui` gives the lane its own rule set for
-# zero mechanism change; a UI branch inside `implement` would generate frontend code
-# under the service lane's standards. (`story-plan` designs BOTH lanes in one run
-# because everything ahead of its authoring step is shared; here nothing is — the
-# lane, the subtree, the rules and the OKF key all differ.)
-#
-# GATES (all loud, all before any write): the frontend lane declared with its source
-# path; a project scaffolded under THAT path specifically — a manifest found only
-# elsewhere is the service lane's, and accepting it is how a frontend that was never
-# built reports green; an active feature; an OPEN story; and that story having a UI
-# design at all. A design behind the current spec, or a story the spec has moved past,
-# is ANNOUNCED, never refused; the route out of both is named.
-#
-# Launch:  /appweaver implement-ui [<story-id>] [guidance]     (asks when ambiguous)
-# Prereq:  /appweaver story-plan (the story's UI design)  ·  Next: /appweaver build
-# =============================================================================
-
-name: aw-spec-implement-ui
-description: "Generate the frontend lane's screens, components, client state and paired tests for ONE STORY, strictly from the LATEST design pass in stories/<ID>/story-frontend-plan.md, bound to the declared UI stack and written only under that lane's source path. Model-driven and design-only — the spec is never a generation input; it appears once afterwards in a read-only acceptance check that reports and never repairs. Consumes interfaces.md by IF- id and never publishes into it. Incremental by contract: it edits the lane's existing tree and MERGES its files into the feature's OKF concept under ui_source_files, so the service lane's list is untouched."
-version: 2.0.0
-agent_agnostic: true
-dialect: aw-spec.orchestrator/v1
-
-inputs:
-  user_input:
-    description: Optional story id and/or implementation guidance (e.g. "Order-001 reuse the shared date picker").
-    required: false
-    bind: USER_INPUT
-
-scripts:
-  actions:
-    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
-    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
-  xref:
-    sh:  .appweaver/scripts/bash/aw-xref.sh
-    ps1: .appweaver/scripts/powershell/aw-xref.ps1
-
-# Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). The lane's
-# FRONTEND code-generation rule files are CONFIGURATION, loaded per-command from
-# guardrails/projects/<project>/tech-rule-bindings.md under `## /aw-spec-implement-ui`
-# by the tech-select module. Per the rule-partition this phase loads NO domain rule
-# file — the domain reached the lane through spec → frontend-plan.md → the story's
-# design pass. The lane's ratified base arrives via constitution.ui.md (referred to
-# directly, as-is — NOT mapped).
-standards:
-  - { path: .appweaver/ai-rules.md }   # kit-resident: the universal operating rules, every flow
-
-vars:
-  feature_dir: ""
-  spec_file: ""
-  # story resolution
-  any_open: "false"
-  open_ids: "[]"
-  digest: ""
-  resolved: "false"
-  needs_pick: "false"
-  pick_reason: ""
-  picked_story: ""
-  story: ""
-  story_path: ""
-  story_open: "false"
-  status_msg: ""
-  story_title: ""
-  exercises_csv: ""
-  constraints_csv: ""
-  current_version: ""
-  stale_csv: ""
-  stale_note: ""
-  story_dir: ""
-  adr_path: ""
-  if_path: ""
-  # the story's UI design (+ the SERVICE design of the same story, for the contract)
-  design_doc: ""
-  design_exists: "false"
-  design_pass: "0"
-  design_spec_version: ""
-  design_stale: "false"
-  service_design_doc: ""
-  # the feature's current code, per lane (OKF)
-  okf_concept: ""
-  coverage_digest: ""
-  fe_source_csv: ""
-  fe_source_count: "0"
-  be_source_count: "0"
-  # generation + enrichment
-  files: ""
-  accept_ok: "true"
-  accept_gaps: ""
-
-workflow:
-
-  # 0. FRONTEND code-generation rule files → sticky standards (configuration, not
-  #    hardcoded). No blocking gate: an unmapped project soft-continues, because
-  #    constitution.ui.md still carries the lane's conventions and forbidden patterns.
-  - id: tech_select
-    action: include
-    module: .appweaver/orchestrator/modules/tech-select.orch.yaml
-    with: { command: aw-spec-implement-ui }
-
-  # 1. The active feature. spec.md is resolved here for the acceptance check ONLY —
-  #    it is not a generation input.
-  - id: feature_paths
-    action: execute_script
-    on_error: continue      # never crash raw on 'no feature set' — the gate below explains it
-    script: { ref: actions }
-    subcommand: feature-paths
-    outputs:
-      - { name: feature_dir, from: "$.feature_dir" }
-      - { name: spec_file,   from: "$.spec_file" }
-  - id: require_feature
-    action: verify_context
-    require_non_empty: feature_dir
-    on_empty: stop
-    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the aggregate, e.g. Order), then re-run implement-ui."
-
-  # 2. WHICH STORY — the same resolution story-plan and implement use.
-  - id: story_scan
-    action: execute_script
-    script: { ref: actions }
-    subcommand: story-plan-check
-    args: ["--feature-dir", "{{feature_dir}}", "--input", "{{USER_INPUT}}"]
-    outputs:
-      - { name: any_open,            from: "$.any_open" }
-      - { name: open_ids,            from: "$.open_ids" }
-      - { name: digest,              from: "$.digest" }
-      - { name: resolved,            from: "$.resolved" }
-      - { name: needs_pick,          from: "$.needs_pick" }
-      - { name: pick_reason,         from: "$.pick_reason" }
-      - { name: story,               from: "$.story" }
-      - { name: story_path,          from: "$.story_path" }
-      - { name: story_open,          from: "$.story_open" }
-      - { name: status_msg,          from: "$.status_msg" }
-      - { name: story_title,         from: "$.story_title" }
-      - { name: exercises_csv,       from: "$.exercises_csv" }
-      - { name: constraints_csv,     from: "$.constraints_csv" }
-      - { name: current_version,     from: "$.current_version" }
-      - { name: stale_csv,           from: "$.stale_csv" }
-      - { name: stale_note,          from: "$.stale_note" }
-      - { name: story_dir,           from: "$.story_dir" }
-      - { name: adr_path,            from: "$.adr_path" }
-      - { name: if_path,             from: "$.if_path" }
-      - { name: design_doc,          from: "$.fe_doc_path" }
-      - { name: design_exists,       from: "$.fe_doc_exists" }
-      - { name: design_pass,         from: "$.fe_last_pass" }
-      - { name: design_spec_version, from: "$.fe_doc_spec_version" }
-      - { name: design_stale,        from: "$.fe_doc_stale" }
-      - { name: service_design_doc,  from: "$.be_doc_path" }
-  - id: require_open_backlog
-    action: verify_context
-    require_true: any_open
-    on_false: stop
-    on_false_message: "No open stories for this feature — there is nothing to implement. Stories are minted by /appweaver specify (bootstrap) and /appweaver sync-stories (when the spec moves)."
-  - id: ask_story
-    condition: "{{needs_pick}} == true"
-    action: ask
-    prompt: |
-      Which story is this UI implementation for? ({{pick_reason}})
-
-      {{digest}}
-    options_from: "{{open_ids}}"
-    answer_key: picked_story
-    answer_var: picked_story
-  - id: story_pick_check
-    condition: "{{needs_pick}} == true"
-    action: execute_script
-    script: { ref: actions }
-    subcommand: story-plan-check
-    args: ["--feature-dir", "{{feature_dir}}", "--story", "{{picked_story}}"]
-    outputs:
-      - { name: resolved,            from: "$.resolved" }
-      - { name: story,               from: "$.story" }
-      - { name: story_path,          from: "$.story_path" }
-      - { name: story_open,          from: "$.story_open" }
-      - { name: status_msg,          from: "$.status_msg" }
-      - { name: story_title,         from: "$.story_title" }
-      - { name: exercises_csv,       from: "$.exercises_csv" }
-      - { name: constraints_csv,     from: "$.constraints_csv" }
-      - { name: stale_csv,           from: "$.stale_csv" }
-      - { name: stale_note,          from: "$.stale_note" }
-      - { name: story_dir,           from: "$.story_dir" }
-      - { name: design_doc,          from: "$.fe_doc_path" }
-      - { name: design_exists,       from: "$.fe_doc_exists" }
-      - { name: design_pass,         from: "$.fe_last_pass" }
-      - { name: design_spec_version, from: "$.fe_doc_spec_version" }
-      - { name: design_stale,        from: "$.fe_doc_stale" }
-      - { name: service_design_doc,  from: "$.be_doc_path" }
-  - id: require_story
-    action: verify_context
-    require_true: resolved
-    on_false: stop
-    on_false_message: |
-      Could not resolve a story from '{{picked_story}}'. Open stories:
-      {{digest}}
-      Re-run implement-ui naming one of them.
-  - id: require_open_story
-    action: verify_context
-    require_true: story_open
-    on_false: stop
-    on_false_message: "{{status_msg}}"
-
-  # 3. THE STORY MUST HAVE A UI DESIGN. A story with a service design and no UI one is
-  #    not a failure — it is a slice with no user-facing surface, and the message says
-  #    so rather than implying something is broken.
-  - id: require_design
-    action: verify_context
-    require_true: design_exists
-    on_false: stop
-    on_false_message: "Story {{story}} has no UI design — {{story_dir}}/story-frontend-plan.md does not exist. Either this slice has no user-facing surface (nothing to do here; run /appweaver implement for the service half), or the UI lane was out of scope when it was designed — a frontend lane that is undeclared, or a frontend-plan.md that is missing or behind the spec, drops that lane from a story-plan run and says so. Fix whichever it was and re-run /appweaver story-plan {{story}}."
-
-  # 3a. Announced, never refused — the same contract implement keeps. design_stale is a
-  #     JSON boolean, so `condition:` does the deciding and the value gate is only the
-  #     vehicle that prints (law 43); stale_csv is a string and compares directly.
-  - id: design_stale_notice
-    condition: "{{design_stale}} == true"
-    action: verify_context
-    require_value: design_stale
-    equals: "false"
-    on_mismatch: continue
-    on_mismatch_message: "UI design pass {{design_pass}} was written against spec {{design_spec_version}} and the spec is now at {{current_version}}. Generating from it is not wrong — the move may not touch this story — but if it does, the code inherits a contract that no longer holds. Re-run /appweaver story-plan {{story}} to design against the current spec, or check the ids named below."
-  - id: story_stale_notice
-    action: verify_context
-    require_value: stale_csv
-    equals: ""
-    on_mismatch: continue
-    on_mismatch_message: "The spec has moved on ids THIS story carries: {{stale_csv}}. Whatever this run generates for them realises superseded wording. Consider /appweaver sync-stories to bring the backlog back in step, then /appweaver story-plan {{story}}, before building."
-
-  # 4. THE FRONTEND LANE and its source path — the only subtree this phase may write
-  #    into, resolved before the project gate that searches it.
-  - id: lane_gate
-    action: include
-    module: .appweaver/orchestrator/modules/lane-gate.orch.yaml
-    with: { require: frontend, command: "/appweaver implement-ui" }
-
-  # 5. Require a frontend PROJECT under the LANE'S OWN path. detect-project searches the
-  #    lane subtree first and falls back to the whole repository, reporting which scope
-  #    answered. THAT DISTINCTION IS THE GATE HERE. A repo-scope hit in a two-lane
-  #    project is the service lane's manifest, and accepting it is exactly the failure
-  #    the lane model exists to prevent — a frontend that was never scaffolded,
-  #    generated into anyway, reporting green.
-  - id: detect_ui_project
-    action: execute_script
-    script: { ref: actions }
-    subcommand: detect-project
-    args: ["--root", "{{lane_source_path}}"]
-    outputs:
-      - { name: ui_project_present, from: "$.scaffolded" }
-      - { name: project_markers,    from: "$.markers" }
-      - { name: project_scope,      from: "$.scope" }
-  - id: ui_project_gate
-    action: verify_context
-    require_value: project_scope
-    equals: "lane"
-    on_mismatch: stop
-    on_mismatch_message: "No frontend project found under the {{lane_id}} lane's source path `{{lane_source_path}}`. implement-ui GENERATES this story's UI into an existing project tree, so one has to be scaffolded there first: run /appweaver foundation <FoundationName> <AppName> where a foundation bundle ships for this stack, or create the project with the stack's own tooling under that path. Any ecosystem manifest inside the lane's path marks it — package.json, go.mod, pyproject.toml, Cargo.toml, pom.xml, build.gradle(.kts) or .sln/.csproj. A manifest found elsewhere in the repository does NOT count: that one belongs to another lane, and generating this lane's code against it is how a frontend that was never built reports green."
-
-  # 6. WHAT ALREADY EXISTS, per lane, from the feature's OKF concept. The UI list is
-  #    what this run edits; the service count tells the pass whether the contract it
-  #    binds to has been built yet. Advisory — a first UI story generates into a clean
-  #    tree and a missing bundle must never block generation.
-  - id: coverage
-    action: execute_script
-    on_error: continue
-    script: { ref: xref }
-    subcommand: concept-coverage
-    args: ["--feature-dir", "{{feature_dir}}", "--ids", "{{exercises_csv}}"]
-    outputs:
-      - { name: okf_concept,     from: "$.concept" }
-      - { name: coverage_digest, from: "$.digest" }
-      - { name: fe_source_csv,   from: "$.frontend_csv" }
-      - { name: fe_source_count, from: "$.frontend_count" }
-      - { name: be_source_count, from: "$.backend_count" }
-
-  # 7. Pre-execution hooks.
-  - id: resolve_pre_hooks
-    action: execute_script
-    script: { ref: actions }
-    subcommand: resolve-hooks
-    args: ["--phase", "before_implement_ui"]
-    outputs:
-      - { name: before_hooks, from: "$.hooks" }
-  - id: dispatch_pre_hooks
-    action: dispatch_hooks
-    hooks_from_variable: before_hooks
-
-  # ═══════════════════ GENERATION — one story's UI slice, one pass ═════════════
-  # The pass constrains WHAT to build; constitution.ui.md, the lane and the loaded
-  # standards fix HOW. spec.md is deliberately absent — the acceptance check below is
-  # where it gets its say.
-  - id: ctx_generate
-    action: build_context
-    vars:
-      story_id: "{{story}}"
-      story_title: "{{story_title}}"
-      exercises_csv: "{{exercises_csv}}"
-      constraints_csv: "{{constraints_csv}}"
-      pass_number: "{{design_pass}}"
-      coverage_digest: "{{coverage_digest}}"
-      ui_source_files_csv: "{{fe_source_csv}}"
-      ui_source_file_count: "{{fe_source_count}}"
-      stale_note: "{{stale_note}}"
-    context:
-      - { path: "{{design_doc}}" }                          # the story's UI design — the LATEST pass is the input
-      - { path: "{{story_path}}" }                          # the story's acceptance criteria — what "done" means
-      - { path: "{{if_path}}", optional: true }             # the PUBLISHED surface this slice binds to, by IF- id
-      - { path: "{{service_design_doc}}", optional: true }  # the SAME story's service design — the newer word on that surface
-      - { path: "{{adr_path}}", optional: true }            # ratified decisions — binding unless a pass supersedes them
-      - { path: .appweaver/memory/constitution.ui.md, optional: true }   # the lane's ratified UX-* base — conventions, forbidden patterns, gates
-  - id: generate
-    action: agent_generate
-    tools: "Read,Write,Edit"       # the existing UI code arrives as {{ui_source_files_csv}} paths, not inlined
-    permission_mode: acceptEdits
-    task: |
-      Implement story {{story_id}} — {{story_title}} — in the frontend lane, from
-      "## Design pass {{pass_number}}" of the UI story design in context.
-      Guidance: {{USER_INPUT}}
-
-      THAT PASS IS THE ONLY SOURCE OF WHAT TO BUILD. It is the LAST pass in the
-      document; every earlier pass is superseded history, and any of them may carry
-      hand edits that were deliberate. Read the last one and build exactly it. Do NOT
-      consult or infer from spec.md — it is not in context on purpose.
-
-      THIS IS ONE SLICE OF AN EXISTING FRONTEND, NOT THE WHOLE FEATURE.
-      - The pass's "### Screens & components" section names, file by file, what to
-        create and what to modify. Create ONLY the files it names as new; modify the
-        named existing files IN PLACE. Every other file belongs to work already done —
-        do not regenerate, reformat or "tidy" it.
-      - The story delivers {{exercises_csv}} and must satisfy {{constraints_csv}}, of
-        which the UX- constraints are yours to realise. Anything outside those ids is
-        another story's work, even if you can see it is missing.
-      - The code that already exists for this feature, per lane, is below. The UI files
-        ({{ui_source_file_count}} on disk) are yours to read before you edit; the
-        service list is there so you can see what the contract is actually backed by.
-
-      {{coverage_digest}}
-
-          {{ui_source_files_csv}}
-
-      BIND THE STACK: this lane is `{{lane_id}}` — {{lane_title}}, language
-      {{lane_language}} ({{lane_ecosystem}}), declared in .appweaver/stacks.json and
-      built with `{{lane_build}}`, tested with `{{lane_test}}`. Generate in THAT
-      framework and no other, using its idioms, its project layout and its test
-      framework. Take the router, state approach, component library, design system and
-      styling from the UI constitution + the loaded standards; the design is
-      technology-agnostic, so do not re-decide anything already fixed there. If the
-      loaded standards describe a DIFFERENT stack than the one above, the lane wins on
-      framework and layout — follow the standards' INTENT and STOP to surface the
-      mismatch in your summary.
-
-      WRITE ONLY UNDER `{{lane_source_path}}` — the source path the `{{lane_id}}` lane
-      declares. NEVER touch the service lane's code, not even to add a field the UI
-      wants: a gap in the service surface is a contract delta raised back to that lane,
-      not a file you edit. Do not create a parallel source tree because the layout
-      inside this one is unfamiliar; if the pass needs a place this subtree has no home
-      for, STOP and surface it.
-
-      Rules:
-      - THE PASS IS THE ONLY DOMAIN INPUT. You have it, the story, and the lane's
-        frontend standards — and NO domain rule files. Introduce NO domain rule,
-        identifier, terminology or behaviour the pass does not state. If a domain
-        specific seems missing, STOP and surface it; never invent it from memory.
-      - Follow the UI constitution's folder structure, naming conventions and forbidden
-        patterns, plus the loaded standards, for HOW to structure, name and place files
-        WITHIN that subtree — the pass says WHAT to build; these say HOW.
-      - REALISE THE PASS EXACTLY, changing nothing about WHAT it specifies:
-        • its "### Approach" — the routes and screens it touches, and where this
-          slice's state lives. Anything the design says must NOT be held never reaches
-          client state, storage, the URL or telemetry.
-        • its "### Screens & components" — each component with the responsibility, the
-          input shapes and the events the pass gives it. Compose the shared components
-          it says it reuses; do not re-implement them.
-        • its "### Contract binding" — call each interface BY ITS IF- id as the pass
-          names it, with the request it states, and render EVERY state it lists:
-          in-flight, empty, error and the failure behaviour. These are requirements,
-          not polish, and they are the first thing a generator drops.
-      - THE CONTRACT IS NOT YOURS TO INVENT. interfaces.md (in context) is the
-        published surface; bind to the latest entry per id. If the pass names an
-        interface the log does not carry, STOP and surface it — do not invent an
-        endpoint, and do not reach into the service lane to add one. Where the SAME
-        story's service design is in context, it is the newer word on what that surface
-        will be; bind to it and say so in your summary.
-      - THE CLIENT IS NOT AN AUTHORITY. A client-side validation or permission check
-        restates a server rule for feedback; it never replaces it. Generate no
-        server-side behaviour, no persistence and no business-rule evaluation here.
-      - ADRs are DECIDED — follow them. The pass may propose a superseding one; a
-        proposal is not yet ratified, so follow the pass and change nothing else.
-      - Author a paired test for every acceptance criterion in the story and every
-        behaviour the pass's "### Tests" section names — including the unwanted-state
-        cases from its contract binding and an accessibility assertion per interactive
-        surface — and cite the requirement id ({{exercises_csv}}, {{constraints_csv}})
-        each test exists for. A snapshot alone is not a test.
-      - Do NOT add behaviour the pass does not state, and do NOT omit any it does. If
-        the pass looks wrong or incomplete, STOP and surface it — it is fixed by
-        re-running /appweaver story-plan, never compensated for here.
-      - This feature OWNS its files; never regenerate a file another feature owns, and
-        do not modify the app shell, global layout or design system — they belong to no
-        feature. If one of them has to change, STOP and surface it.
-      {{stale_note}}
-    outputs:
-      - { name: files, from: "$.files" }
-
-  - id: verify_generated
-    action: verify_context
-    require_non_empty: files
-    on_empty: stop
-    on_empty_message: "No files generated for story {{story}}. Check that UI design pass {{design_pass}} in {{design_doc}} actually describes changes (a pass whose '### Screens & components' section is empty has nothing to build), then re-run — or re-run /appweaver story-plan {{story}} to design the slice properly first."
-
-  # 8. OKF — MERGE, into the UI LANE'S KEY. The feature has ONE concept across both
-  #    lanes: `--lane frontend` writes `ui_source_files`, so the service lane's
-  #    `source_files` is untouched whichever lane implements first, and `--merge` unions
-  #    this story's files with what the feature's earlier UI stories wrote. The
-  #    concept's Overview is NOT re-authored here: it describes the aggregate and its
-  #    invariants, which is the service design's subject, and rewriting it from a UI
-  #    slice would trade a domain description for an experience one.
-  - id: xref_concept
-    action: execute_script
-    script: { ref: xref }
-    subcommand: concept-upsert
-    args: ["--feature-dir", "{{feature_dir}}", "--source-files", "{{files}}", "--merge", "--lane", "frontend", "--origin", "greenfield"]
-    outputs:
-      - { name: okf_concept, from: "$.concept" }
-
-  # ═══════════════ ACCEPTANCE — the ONE place the spec is read ═════════════════
-  # READ-ONLY and REPORT-ONLY: it never edits code, never edits the pass, and never
-  # stops the run. A gap means one of two documents is wrong, and which one is a human
-  # decision — the message names both routes.
-  - id: ctx_accept
-    action: build_context
-    vars:
-      story_id: "{{story}}"
-      exercises_csv: "{{exercises_csv}}"
-      constraints_csv: "{{constraints_csv}}"
-      files_csv: "{{files}}"
-    context:
-      - { path: "{{story_path}}" }    # the acceptance criteria
-      - { path: "{{spec_file}}" }     # the contract — the ONLY step in this workflow that reads it
-      - { path: "{{design_doc}}" }    # what was designed
-  - id: accept_check
-    action: agent_query
-    tools: Read                       # the generated files arrive as paths, not inlined
-    include_standards: false
-    schema: { ok: "<true|false>", gaps: "<one line per gap, or empty>" }
-    mock: { ok: "true", gaps: "" }
-    task: |
-      Story {{story_id}} was just implemented in the frontend lane. Judge ONLY this:
-      does the UI that now exists satisfy the requirements the story delivers, AS THE
-      SPEC WORDS THEM?
-
-      In scope: {{exercises_csv}} (delivered) and {{constraints_csv}} (must hold) — the
-      UX- ids among them are this lane's to realise. Resolve each id's wording from
-      spec.md in context; that wording, not the design's restatement of it, is what the
-      code is measured against.
-
-      Read the files this run wrote:
-          {{files_csv}}
-      plus anything they import that you need to follow. Do not modify a single file.
-
-      Report a gap ONLY where the UI fails to deliver an in-scope id as the spec words
-      it, or breaks an in-scope constraint. These are NOT gaps, and reporting them is
-      noise that hides the real ones:
-      - server-side behaviour — this lane cannot implement it and must not;
-      - a requirement no story has claimed yet, or one another story delivers;
-      - style, naming, structure or test-coverage opinions — other gates own those;
-      - anything the design pass deliberately deferred and named under its risks.
-
-      One line per gap: the id, what the spec requires, and what the UI does instead.
-      Set ok=false only when you found at least one. If the SPEC and the DESIGN disagree
-      about an in-scope id, that IS a gap — say which document you believe is wrong and
-      why, because the two routes out of it are different commands.
-    outputs:
-      - { name: accept_ok,   from: "$.ok" }
-      - { name: accept_gaps, from: "$.gaps" }
-  - id: accept_notice
-    condition: "{{accept_ok}} != true"
-    action: verify_context
-    require_value: accept_ok
-    equals: "true"
-    on_mismatch: continue
-    on_mismatch_message: |
-      ACCEPTANCE — story {{story}}'s UI does not yet satisfy the spec wording of the ids it delivers:
-
-      {{accept_gaps}}
-
-      Nothing was changed to fix this: the code follows UI design pass {{design_pass}}, so a gap
-      here means either the design was wrong or the spec has moved. Route by which it is —
-      the design is wrong: /appweaver story-plan {{story}} (a new pass supersedes this one);
-      the spec is wrong: /appweaver sync-spec, then sync-stories, then story-plan.
-      Run /appweaver build either way — a design that is right and code that does not compile
-      is a third thing, and build is where that one surfaces.
-
-  # 9. Post-execution hooks.
-  - id: resolve_post_hooks
-    action: execute_script
-    script: { ref: actions }
-    subcommand: resolve-hooks
-    args: ["--phase", "after_implement_ui"]
-    outputs:
-      - { name: after_hooks, from: "$.hooks" }
-  - id: dispatch_post_hooks
-    action: dispatch_hooks
-    hooks_from_variable: after_hooks
-
-outputs:
-  story: "{{story}}"
-  built_from: "{{design_doc}} — UI design pass {{design_pass}} (designed against spec {{design_spec_version}}; spec now {{current_version}})"
-  requirements: "{{exercises_csv}}"
-  files: "{{files}}"
-  lane: "{{lane_id}} → {{lane_source_path}}"
-  okf_concept: "{{okf_concept}} (this run's files MERGED into ui_source_files; the service lane's source_files is untouched)"
-  acceptance: "ok={{accept_ok}} · gaps: {{accept_gaps}}"
-  stale_ids: "{{stale_csv}}"
-  next: "/appweaver build — it compiles every declared lane, so a break in either surfaces there. Then /appweaver analyze-slice. The story stays OPEN until /appweaver close-story ratifies its ADRs, flips its interface entries live and archives the passes."