aw-spec-cli 0.1.5 → 0.1.7

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

@@ -1,231 +0,0 @@
-# =============================================================================
-# aw-spec-implement-delta (orchestrator) — generate the DELTA's code from the design
-#
-# The CR analog of implement, SCOPED to the open change. GENERATE / edit exactly the
-# source files + paired tests that delta-design.md marks ADDED or MODIFIED, into the
-# existing project tree, using the master design.md as the base context. The delta
-# design is the authoritative source for WHAT the change is — analyze-delta-design already
-# conformed it to the delta spec. The target STACK is bound from the constitution.
-# implement-delta does NOT touch spec.md / design.md and does NOT close the change —
-# finalize-delta merges the delta into the master docs afterward, and close-delta bumps
-# the version at the very end.
-#
-#   specify → design → ⟨review⟩ → analyze-delta-design → implement-delta   ← you are here
-#       → build → finalize-delta → analyze-slice → close-delta
-#
-# Prereqs: run /aw-spec-orch analyze-delta-design first (the delta design is conformed),
-# and the project must already be scaffolded (/aw-spec-orch foundation) — implement-delta
-# GENERATES into that tree.
-#
-# Launch:  /aw-spec-orch implement-delta [strategy] [guidance]
-# =============================================================================
-
-name: aw-spec-implement-delta
-description: Generate only the source files + paired tests the open change's delta-design.md marks ADDED/MODIFIED, into the existing project tree, bound to the project's stack. Model-driven, delta-design-scoped; does not touch the master docs or close the change.
-version: 1.0.0
-agent_agnostic: true
-dialect: aw-spec.orchestrator/v1
-
-inputs:
-  user_input:
-    description: Optional implementation guidance (stack hints, focus area).
-    required: false
-    bind: USER_INPUT
-
-scripts:
-  actions:
-    sh:  .aw-spec/scripts/bash/aw-spec-actions.sh
-    ps1: .aw-spec/scripts/powershell/aw-spec-actions.ps1
-  xref:
-    sh:  .aw-spec/scripts/bash/aw-xref.sh
-    ps1: .aw-spec/scripts/powershell/aw-xref.ps1
-
-# Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). Same FRAMEWORK /
-# code-generation set as the forward implement — HOW to build — but no longer hardcoded:
-# it is CONFIGURATION, loaded per-command from docs/domainspecs/<domain>/commandtechrulemap.md
-# by the tech-select module (see the tech_select step below). No domain rule files:
-# everything domain reached the delta via delta-spec → delta-design; the tech map lists
-# only technical files. The architecture principles come via constitution.technical.md
-# (referred to directly, as-is — NOT mapped); the structure via design.md. (missing skipped)
-standards:
-  - { path: docs/glossary/ai-rules.md, optional: true }
-
-workflow:
-
-  # 0. TECHNICAL rule files → sticky standards (configuration, not hardcoded).
-  #    tech-select reads docs/domainspecs/<domain>/commandtechrulemap.md under
-  #    "## /aw-spec-implement-delta" and loads that set into the sticky standards the
-  #    agent_generate step ALWAYS prepends. No domain rule file is loaded here — the tech
-  #    map lists only technical files (rule-partition intact). No blocking gate: an
-  #    unconfigured project soft-continues (constitution.technical.md still carries the
-  #    tech base, referred to directly below).
-  - id: tech_select
-    action: include
-    module: .aw-spec/orchestrator/modules/tech-select.orch.yaml
-    with: { command: aw-spec-implement-delta }
-
-  # 1. Resolve the current feature + its master design (the base context).
-  - 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: design_doc,    from: "$.design_file" }
-      - { name: design_exists, from: "$.design_exists" }
-
-  - id: require_feature
-    action: verify_context
-    require_non_empty: feature_dir
-    on_empty: stop
-    on_empty_message: "No active feature. Run /aw-spec-orch select-feature first (pick or create the aggregate, e.g. Order), then re-run implement-delta."
-
-  - id: verify_design
-    action: verify_context
-    require_true: design_exists
-    on_false: stop
-    on_false_message: "No design.md for the current feature. Run /aw-spec-orch design (and, for a change, /aw-spec-orch specify + design + analyze-delta-design) first."
-
-  # 1b. Read the OPEN change (opened by cr). implement-delta needs a change to implement.
-  - id: read_change
-    action: execute_script
-    script: { ref: actions }
-    subcommand: version-read
-    args: ["--feature-dir", "{{feature_dir}}"]
-    outputs:
-      - { name: active_change, from: "$.active_change" }
-      - { name: has_change,    from: "$.has_change" }
-
-  - id: require_change
-    action: verify_context
-    require_true: has_change
-    on_false: stop
-    on_false_message: "No open change on this feature. Run /aw-spec-orch specify <change> then /aw-spec-orch design, review the delta docs, and /aw-spec-orch analyze-delta-design before implement-delta."
-
-  # 1c. Require the FOUNDATION — a scaffolded, compiling project — to be present.
-  #     implement-delta GENERATES the delta's code INTO that tree; with no project there
-  #     is nowhere to place the files.
-  - id: detect_foundation
-    action: execute_script
-    script: { ref: actions }
-    subcommand: detect-project
-    outputs:
-      - { name: foundation_present, from: "$.scaffolded" }
-      - { name: project_markers,    from: "$.markers" }
-
-  - id: foundation_gate
-    action: verify_context
-    require_true: foundation_present
-    on_false: stop
-    on_false_message: "No scaffolded project found — run /aw-spec-orch foundation <FoundationName> <AppName> first. implement-delta GENERATES the delta's code into the foundation's project tree (.sln/.csproj); there is nowhere to place files without it."
-
-  # 2. Pre-execution hooks.
-  - id: resolve_pre_hooks
-    action: execute_script
-    script: { ref: actions }
-    subcommand: resolve-hooks
-    args: ["--phase", "before_implement_cr"]
-    outputs:
-      - { name: before_hooks, from: "$.hooks" }
-  - id: dispatch_pre_hooks
-    action: dispatch_hooks
-    hooks_from_variable: before_hooks
-
-  # 3. Model-driven generation SCOPED to the delta: delta-design.md → the ADDED/MODIFIED
-  #    source files + paired tests. The master design.md is the base (unchanged elements
-  #    the delta depends on); the constitution/stack profile fixes HOW. The delta spec is
-  #    in context ONLY to cite traceability ids on the paired tests.
-  # Context is fed via build_context — agent_generate reads the ENVELOPE, not a
-  # step-level context: key (unlike agent_author/agent_query which read both).
-  - id: ctx_generate
-    action: build_context
-    context:
-      - { path: "{{feature_dir}}/changes/{{active_change}}/delta-design.md" }
-      - { path: "{{feature_dir}}/changes/{{active_change}}/delta-spec.md" }
-      - { path: "{{design_doc}}" }
-      - { path: .aw-spec/memory/constitution.technical.md, optional: true } # technology base ONLY — no domain
-  - id: generate
-    action: agent_generate
-    tools: "Read,Write,Edit"
-    permission_mode: acceptEdits
-    task: |
-      Implement ONLY this change into the existing project tree, STRICTLY from its
-      delta-design.md (in context). The delta design is the authoritative source of
-      WHAT changed — analyze-delta-design already conformed it to the delta spec. The
-      master design.md (in context) is the BASE: the unchanged elements the delta
-      depends on; do NOT regenerate them. Guidance: {{USER_INPUT}}
-      Rules:
-      - SCOPE = THE DELTA ONLY. Realise exactly the elements delta-design.md marks
-        ADDED (create the new file) or MODIFIED (edit the existing file in place).
-        Touch NOTHING the delta does not list, except the regression re-tests below.
-      - THE DELTA DESIGN IS THE ONLY DOMAIN INPUT. You have the delta design + master
-        design.md + framework/code standards, and NO domain rule files. Introduce NO
-        domain rule, identifier, terminology, or behaviour the delta design does not
-        state. If something domain seems missing, STOP and surface it (fix it in cr /
-        analyze-delta-design); never invent it from memory.
-      - BIND THE STACK from the constitution's technology base + the active stack
-        profile (language, framework, persistence, test framework). The design is
-        technology-agnostic; do not re-decide anything the constitution already fixes.
-      - Follow the project's existing folder/layer convention + the loaded
-        coding-standards, dependency-policy and testing standards for HOW to structure,
-        name, and place files. Match the surrounding code already in the tree.
-      - Realise EVERY ADDED/MODIFIED delta element as code: one file per Domain type /
-        Application use-case / API endpoint / Infrastructure adapter, placed by layer.
-        Preserve the ubiquitous-language names verbatim. Enforce each new/changed
-        Domain invariant, handler orchestration, API error contract, and the §5
-        cross-cutting realisations (audit / retention / data-exposure — CN-/DC-) and
-        §4.2 integration contracts (IC-) exactly as the delta design states.
-      - COMPONENTS: if a delta element depends on a framework component, code against
-        its ABSTRACTION / port as the delta design declares — do NOT hand-roll it.
-        Installing the component (packages, wiring, config) is /aw-spec-orch
-        add-component <Component>; if the port isn't present, code to it and note that
-        as the prerequisite.
-      - Author a paired test for every ADDED/MODIFIED behaviour / use-case / endpoint;
-        derive the cases from the delta design's pre/post/invariant contracts and cite
-        the delta-spec id (FR / BR / CN / DC / IC / US).
-      - REGRESSION: for each element in the delta design's "Regression targets", verify
-        (add/adjust a test where needed) that the existing behaviour still holds after
-        a shared element changed — but do NOT rewrite that existing behaviour.
-      - Where generated code depends on a delta Assumption (DA-n) / Workaround (WA-n),
-        mark it with a comment citing that id.
-    outputs:
-      - { name: files, from: "$.files" }
-
-  - id: verify_generated
-    action: verify_context
-    require_non_empty: files
-    on_empty: stop
-    on_empty_message: "No files generated. Ensure /aw-spec-orch design produced a filled delta-design.md (not the empty template) and it passed /aw-spec-orch analyze-delta-design, then re-run."
-
-  # 3b. Refresh THIS slice's OKF concept source_files with the delta's changed files —
-  #     UNION, never replace (the delta is scoped; {{files}} is only the ADDED/MODIFIED
-  #     files). The cross-slice EDGES are refreshed later in finalize-delta, AFTER the delta
-  #     merges into the master design.md (here the master still holds the pre-change deps,
-  #     so recording edges now would read stale references). Best-effort enrichment.
-  - id: xref_concept_merge
-    action: execute_script
-    on_error: continue
-    script: { ref: xref }
-    subcommand: concept-upsert
-    args: ["--feature-dir", "{{feature_dir}}", "--source-files", "{{files}}", "--merge"]
-    outputs:
-      - { name: okf_concept, from: "$.concept" }
-
-  # 4. Post-execution hooks.
-  - id: resolve_post_hooks
-    action: execute_script
-    script: { ref: actions }
-    subcommand: resolve-hooks
-    args: ["--phase", "after_implement_cr"]
-    outputs:
-      - { name: after_hooks, from: "$.hooks" }
-  - id: dispatch_post_hooks
-    action: dispatch_hooks
-    hooks_from_variable: after_hooks
-
-outputs:
-  feature_dir: "{{feature_dir}}"
-  cr_id: "{{active_change}}"
-  files: "{{files}}"
-  next: "/aw-spec-orch build → finalize-delta → analyze-slice → close-delta. COMPILE FIRST (build), then finalize-delta runs the downstream fence and merges the delta into spec.md + design.md — but leaves the change OPEN. analyze-slice then verifies the slice against that now-merged master (tests, domain conformance, referrer blast radius) while a red result is still recoverable. close-delta LAST archives the change and bumps the version."

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

@@ -1,258 +0,0 @@
-# =============================================================================
-# aw-spec-implement (orchestrator) — model-driven code generation from the DESIGN
-#
-# The spec-anchored Implement phase: GENERATE the source files + paired tests for
-# the aggregate STRICTLY from its single high-level design.md — the mediator between
-# spec and code. Implement does NOT read spec.md: `analyze` already guaranteed the
-# design conforms to the spec (spec is the anchor), so the design is the complete,
-# authoritative source for WHAT to build. The target STACK is bound here from the
-# constitution + the active stack profile (the design is technology-agnostic).
-# Prereqs: run /aw-spec-orch design then analyze-design first (the gate conforms the
-# design to the spec + closes any open change), and scaffold the project once via
-# /aw-spec-orch foundation — implement GENERATES into that project tree, so with no
-# foundation there is nowhere to place the files.
-#
-# Next: Build (compile + fix; reconcile only high-level variations into design.md).
-#
-# Launch:  /aw-spec-orch implement [strategy] [guidance]
-# =============================================================================
-
-name: aw-spec-implement
-description: Generate the aggregate's source files and paired tests STRICTLY from its design.md, bound to the project's stack. Model-driven, design-only (does not read the spec — analyze already conformed the design to it).
-version: 2.1.0
-agent_agnostic: true
-dialect: aw-spec.orchestrator/v1
-
-inputs:
-  user_input:
-    description: Optional implementation guidance (stack hints, focus area).
-    required: false
-    bind: USER_INPUT
-
-scripts:
-  actions:
-    sh:  .aw-spec/scripts/bash/aw-spec-actions.sh
-    ps1: .aw-spec/scripts/powershell/aw-spec-actions.ps1
-  xref:
-    sh:  .aw-spec/scripts/bash/aw-xref.sh
-    ps1: .aw-spec/scripts/powershell/aw-xref.ps1
-
-# Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). The
-# FRAMEWORK / code-generation rule files are no longer hardcoded here — they are now
-# CONFIGURATION, loaded per-command from docs/domainspecs/<domain>/commandtechrulemap.md
-# by the tech-select module (see the workflow's tech_select step), exactly as design's
-# technical rules are. Per the rule-partition, implement still generates from design.md +
-# these HOW-to-build standards and loads NO domain rule file — the tech map lists only
-# technical files. The architecture principles come via constitution.technical.md
-# (referred to directly, as-is — NOT mapped); the structure via design.md. Component
-# rule docs are NOT loaded here — implement codes against a component's PORT; adding the
-# component itself is a separate step, /aw-spec-orch add-component. (missing files skipped)
-standards:
-  - { path: docs/glossary/ai-rules.md, optional: true }
-
-workflow:
-
-  # 0. TECHNICAL rule files → sticky standards (configuration, not hardcoded).
-  #    tech-select reads docs/domainspecs/<domain>/commandtechrulemap.md under
-  #    "## /aw-spec-implement" and loads that set into the sticky standards the
-  #    agent_generate step ALWAYS prepends. No domain rule file is loaded here — the
-  #    tech map lists only technical files (rule-partition intact). No blocking gate:
-  #    an unconfigured project soft-continues (constitution.technical.md still carries
-  #    the tech base, referred to directly below).
-  - id: tech_select
-    action: include
-    module: .aw-spec/orchestrator/modules/tech-select.orch.yaml
-    with: { command: aw-spec-implement }
-
-  # 1. Resolve the current feature + its design; require the DESIGN (implement's
-  #    only input). No spec — analyze already conformed the design to the spec.
-  - 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: design_doc,    from: "$.design_file" }
-      - { name: design_exists, from: "$.design_exists" }
-
-  - id: require_feature
-    action: verify_context
-    require_non_empty: feature_dir
-    on_empty: stop
-    on_empty_message: "No active feature. Run /aw-spec-orch select-feature first (pick or create the aggregate, e.g. Order), then re-run implement."
-
-  - id: verify_design
-    action: verify_context
-    require_true: design_exists
-    on_false: stop
-    on_false_message: "No design.md for the current feature. Run /aw-spec-orch design then /aw-spec-orch analyze-design first — implement generates STRICTLY from the conformed design."
-
-  # 1b. Require the FOUNDATION — a scaffolded, compiling project — to be present.
-  #     Implement GENERATES the aggregate's code INTO the project tree the `foundation`
-  #     phase unpacked; with no project there is nowhere to place the files. Deterministic
-  #     structure gate: looks for a real .sln/.csproj (or other ecosystem manifest),
-  #     ignoring the framework/spec/docs dirs — never trusts the model for this.
-  - id: detect_foundation
-    action: execute_script
-    script: { ref: actions }
-    subcommand: detect-project
-    outputs:
-      - { name: foundation_present, from: "$.scaffolded" }
-      - { name: project_markers,    from: "$.markers" }
-
-  - id: foundation_gate
-    action: verify_context
-    require_true: foundation_present
-    on_false: stop
-    on_false_message: "No scaffolded project found — run /aw-spec-orch foundation <FoundationName> <AppName> first. Implement GENERATES code into the foundation's project tree (.sln/.csproj); there is nowhere to place files without it."
-
-  # 2. Pre-execution hooks.
-  - id: resolve_pre_hooks
-    action: execute_script
-    script: { ref: actions }
-    subcommand: resolve-hooks
-    args: ["--phase", "before_implement"]
-    outputs:
-      - { name: before_hooks, from: "$.hooks" }
-  - id: dispatch_pre_hooks
-    action: dispatch_hooks
-    hooks_from_variable: before_hooks
-
-  # 3. Model-driven generation: design.md → source files + paired tests.
-  #    The design constrains WHAT to build; the constitution/stack profile fixes HOW.
-  #    The spec is deliberately NOT in context — the design is the single source here.
-  - id: ctx_generate
-    action: build_context
-    context:
-      - { path: "{{design_doc}}" }
-      - { path: .aw-spec/memory/constitution.technical.md, optional: true } # technology base ONLY — no domain
-  - id: generate
-    action: agent_generate
-    tools: "Read,Write,Edit"
-    permission_mode: acceptEdits
-    task: |
-      Generate the production code AND paired tests for this aggregate STRICTLY from
-      its design.md (in context). The design is the complete, authoritative source of
-      WHAT to build — do NOT consult or infer from the spec; `analyze` already
-      conformed the design to the spec. This phase is the HOME of the
-      technology-specific, solution-wide code-generation rules. Guidance: {{USER_INPUT}}
-      Rules:
-      - THE DESIGN IS THE ONLY DOMAIN INPUT. You have design.md + framework/code
-        standards, and NO domain rule files. Introduce NO domain rule, identifier,
-        terminology, or behaviour that the design does not state — everything domain
-        already passed through spec → design. If a domain specific seems missing, STOP
-        and surface it; never invent it from memory.
-      - BIND THE STACK from the constitution's technology base + the active stack
-        profile (language, framework, persistence, test framework). The design is
-        technology-agnostic; do not re-decide anything the constitution already fixes.
-      - Follow the project's folder/layer convention + the loaded coding-standards,
-        dependency-policy and testing standards for HOW to structure, name, and place
-        files — the design says WHAT to build; these standards (identical for every
-        feature) say HOW.
-      - COMPONENTS: when the design's §4.2 depends on a framework component (e.g.
-        `IEmailService`, `IJobScheduler`), code against that component's ABSTRACTION /
-        port as the design declares — do NOT hand-roll it. Installing the component into
-        the project (packages, provider wiring, config) is a SEPARATE step:
-        /aw-spec-orch add-component <Component>. If the port isn't present yet, code to
-        it and note add-component as the prerequisite; do not load component rule docs here.
-      - Realise EVERY design element as code, changing nothing about WHAT it specifies:
-        one file per Domain type / Application use-case / API endpoint / Infrastructure
-        adapter, placed by layer. Preserve the ubiquitous-language names verbatim.
-      - Enforce EXACTLY as the design states: every Domain invariant, Application
-        handler orchestration, and API error contract; the cross-cutting constraints in
-        §5 (audit / retention / data-exposure — the CN-/DC- realisations); and each
-        §4.2 integration contract (IC-). Implement every port the design declares.
-      - Author a paired test for every design behaviour / use-case / endpoint; derive
-        the cases from the design's pre/post/invariant contracts and cite the spec id
-        (FR / BR / CN / DC / IC / US) from the design's §6 Traceability. Include tests
-        for the constraints — e.g. an audit record is emitted, a DC-restricted field is
-        NOT exposed on the public surface, an IC- projection round-trips.
-      - Do NOT add behaviour the design does not state, and do NOT omit any it does.
-        If the design looks wrong or incomplete, STOP and surface it (it is fixed in
-        design/analyze) — never compensate from the spec or from memory.
-      - This aggregate OWNS its files; never regenerate a file another feature owns.
-      - Where generated code depends on a design Assumption (DA-n) or Workaround
-        (WA-n), mark it with a comment citing that id so it is easy to revisit later.
-    outputs:
-      - { name: files, from: "$.files" }
-
-  - id: verify_generated
-    action: verify_context
-    require_non_empty: files
-    on_empty: stop
-    on_empty_message: "No files generated. Ensure /aw-spec-orch design produced a filled design.md (not the empty template) and passed analyze, then re-run."
-
-  # 3b. OKF knowledge + cross-references (deterministic, design-derived). Greenfield's
-  #     entry into the shared OKF bundle: author THIS aggregate's concept (its source_files
-  #     = the files just generated), then record its cross-slice edges — write a
-  #     Cross-References row into every SIBLING aggregate it uses (from design.md §1
-  #     References-by-id + its External integrations table), reconcile-on-write so a dropped
-  #     dependency self-heals and a used sibling with no concept yet is stubbed. Finally
-  #     author the concept's Overview prose (3c). This is enrichment downstream of a
-  #     successful generate — it never re-decides WHAT was built.
-  - id: xref_concept
-    action: execute_script
-    script: { ref: xref }
-    subcommand: concept-upsert
-    args: ["--feature-dir", "{{feature_dir}}", "--source-files", "{{files}}", "--origin", "greenfield"]
-    outputs:
-      - { name: okf_concept, from: "$.concept" }
-
-  - id: xref_record
-    action: execute_script
-    script: { ref: xref }
-    subcommand: record
-    args: ["--feature-dir", "{{feature_dir}}", "--design", "{{design_doc}}", "--origin", "greenfield"]
-    outputs:
-      - { name: xref_wrote,      from: "$.wrote" }
-      - { name: xref_edge_count, from: "$.edge_count" }
-
-  # 3c. The concept's Overview — the ONE part of the OKF concept a deterministic script
-  #     cannot produce (prose distilled from design.md §1). The model authors the text
-  #     only; concept-overview splices it into the `## Overview` section alone, so the
-  #     Cross-References rows other slices own are structurally out of reach.
-  - id: okf_overview
-    action: agent_query
-    context: ["{{design_doc}}"]
-    include_standards: false
-    schema: { overview: "<2-4 sentences of prose>" }
-    mock: { overview: "" }
-    task: |
-      Write the OKF knowledge-concept Overview for the aggregate that design.md (in
-      context) describes. 2-4 sentences of PROSE, distilled from §1 Domain Model:
-      - name the aggregate ROOT and what the aggregate IS;
-      - state the INVARIANTS it guards (from §1 / the design's business rules);
-      - state its TRANSACTION BOUNDARY — what it OWNS inside the boundary vs what it
-        only REFERENCES by id.
-      Plain prose only: no headings, no bullets, no code fences, no file paths, and no
-      restating of the dependency edges (those live in the Depends-On / Cross-References
-      tables). Describe only what the design states — invent nothing.
-    outputs:
-      - { name: okf_overview, from: "$.overview" }
-
-  - id: okf_overview_write
-    action: execute_script
-    script: { ref: xref }
-    subcommand: concept-overview
-    args: ["--feature-dir", "{{feature_dir}}", "--text", "{{okf_overview}}"]
-
-  # 4. Post-execution hooks.
-  - id: resolve_post_hooks
-    action: execute_script
-    script: { ref: actions }
-    subcommand: resolve-hooks
-    args: ["--phase", "after_implement"]
-    outputs:
-      - { name: after_hooks, from: "$.hooks" }
-  - id: dispatch_post_hooks
-    action: dispatch_hooks
-    hooks_from_variable: after_hooks
-
-outputs:
-  feature_dir: "{{feature_dir}}"
-  design_doc: "{{design_doc}}"
-  files: "{{files}}"
-  okf_concept: "{{okf_concept}}"
-  xref_edge_count: "{{xref_edge_count}}"
-  next: "/aw-spec-orch build  (OKF concept authored at {{okf_concept}}; {{xref_edge_count}} cross-slice edge(s) recorded into sibling aggregates)"