gaia-framework 1.57.0 → 1.57.2

package/_gaia/lifecycle/workflows/3-solutioning/implementation-readiness/instructions.xml

@@ -1,160 +0,0 @@
-<workflow name="implementation-readiness">
-<critical>
-  <mandate>Output must include machine-readable PASS/FAIL gate report</mandate>
-  <mandate>Check ALL artifacts — do not stop at first failure</mandate>
-  <mandate>If the traceability matrix declares its own gate as BLOCKED or FAIL, the readiness report MUST NOT declare traceability_complete: true. Either declare FAIL, or declare CONDITIONAL PASS with explicit justification including the implementation rate percentage.</mandate>
-</critical>
-<step n="1" title="Load All Artifacts">
-  <action>Load PRD, UX Design, Architecture, Epics/Stories</action>
-  <action>Load {test_artifacts}/traceability-matrix.md — extract requirement coverage summary</action>
-  <action>Load {test_artifacts}/ci-setup.md — extract pipeline quality gates summary</action>
-  <action>Load {test_artifacts}/test-plan.md if exists — extract risk assessment</action>
-  <action>Note any missing artifacts immediately</action>
-</step>
-<step n="2" title="Completeness Check">
-  <action>Verify each document exists and has all required sections</action>
-  <action>PRD: overview, personas, requirements, NFRs, journeys, data, integrations, constraints, criteria</action>
-  <action>Architecture: stack, system design, data, API, infrastructure</action>
-  <action>Epics: at least 1 epic with stories, all stories have AC</action>
-</step>
-<step n="3" title="Consistency Check">
-  <action>Verify stories trace to PRD requirements</action>
-  <action>Verify architecture covers all functional areas</action>
-  <action>Verify prd.md contains a "## Review Findings Incorporated" section — confirms adversarial review findings were consumed</action>
-  <action>Verify architecture.md contains a "## Review Findings Incorporated" section — confirms adversarial review findings were consumed</action>
-  <action>Check for terminology consistency across documents</action>
-</step>
-<step n="4" title="Cross-Artifact Contradiction Check">
-  <action>Load decision-authority-matrix from {project-root}/_gaia/core/protocols/agent-specification-protocol.md — extract domain/authority mappings for contradiction reporting</action>
-  <action>CHECK 1 — Architecture vs Threat Model (skip if {planning_artifacts}/threat-model.md does not exist — log "INFO: threat model not available, architecture/security cross-check skipped"):
-    Extract security requirements (SR-*) and mitigations from threat-model.md.
-    For each SR-*, verify architecture.md contains a component, design decision, or ADR that addresses it.
-    Flag unaddressed SR-* items as contradictions. Authority: security (Zara). Severity: BLOCKING if Critical/High, WARNING if Medium/Low.</action>
-  <action>CHECK 2 — Architecture vs Infrastructure Design (skip if {planning_artifacts}/infrastructure-design.md does not exist — log "INFO: infrastructure design not available, topology cross-check skipped"):
-    Compare deployment topology in infrastructure-design.md against system architecture section in architecture.md.
-    Flag mismatches: architectural style vs deployment model, service boundaries vs container boundaries, communication patterns vs networking design.
-    Authority: deployment-topology decisions → Soren, component-boundary decisions → Theo. Severity: BLOCKING.</action>
-  <action>CHECK 3 — Architecture vs Stories:
-    Extract architecture components from architecture.md (services, databases, APIs, external integrations).
-    Scan epics-and-stories.md for component references.
-    Flag: (a) stories referencing components not in architecture — BLOCKING, (b) architecture components with no corresponding stories — WARNING.</action>
-  <action>CHECK 4 — PRD NFRs vs Architecture:
-    Extract quantified NFR targets from prd.md (performance, availability, scalability, security).
-    Verify each has a corresponding architecture design decision or ADR.
-    Flag unaddressed NFRs. Authority: architect (Theo). Severity: WARNING for non-security NFRs, BLOCKING for security NFRs.</action>
-  <action>CHECK 5 — Threat Model vs Stories (skip if threat-model.md does not exist):
-    Extract Critical and High risk security requirements (SR-*) from threat-model.md.
-    Verify each has at least one story whose acceptance criteria addresses it.
-    Flag unaddressed Critical/High SR-* items. Authority: security (Zara). Severity: BLOCKING.</action>
-  <action>CHECK 6 — Auth Strategy Alignment:
-    Extract auth strategy from architecture.md API Design section.
-    Compare against: (a) auth requirements in prd.md, (b) auth-related mitigations in threat-model.md (if exists).
-    Flag mismatches in auth mechanism, session management, or token strategy. Authority: security (Zara). Severity: BLOCKING.</action>
-  <action>Record all contradictions in a structured list:
-    For each: contradiction_id (C-1, C-2, ...), type, source_artifacts, description, authority_agent, severity (BLOCKING/WARNING), recommended_resolution.
-    Count BLOCKING contradictions. If count > 0: set contradiction_check = FAIL. Else: PASS.</action>
-</step>
-<step n="5" title="TEA Readiness">
-  <action>TECHNICAL: Evaluate team expertise against chosen stack from architecture.md. Flag any technologies with no prior team experience. Estimate learning curve risk (Low/Medium/High).</action>
-  <action>ESTIMATION: Check if stories in epics-and-stories.md use numeric story points. Flag T-shirt sizing (S/M/L/XL) without point equivalents as an estimation gap. Flag oversized stories (>13 points) as needing decomposition.</action>
-  <action>ARCHITECTURE: Count ADRs in architecture.md. Flag any with Status: Proposed (unresolved). Check if adversarial review findings were incorporated. Check threat model risk level if threat-model.md exists.</action>
-  <action>TESTING: Is test strategy defined? Are acceptance criteria testable and automatable? Are NFR targets quantified for performance testing?</action>
-</step>
-<step n="6" title="Test Infrastructure Readiness">
-  <action>Verify traceability-matrix.md covers all PRD requirements — flag uncovered requirements as blocking</action>
-  <action>Extract the traceability matrix's own gate decision: search traceability-matrix.md for the "implementation-readiness gate:" field (or equivalent quality gate section). Record the value as traceability_gate_decision (PASS, BLOCKED, or FAIL). If the field does not exist, record as "NOT_DECLARED".</action>
-  <action>Extract the test implementation rate from traceability-matrix.md: find the total planned tests vs implemented tests count (e.g., "Implemented: 10/109"). Calculate and record as traceability_implementation_rate: {N}%. If not declared, record as "unknown".</action>
-  <action>Verify ci-setup.md defines enforced quality gates (coverage %, pass rate thresholds) — flag advisory-only gates as a warning</action>
-  <action>Verify test-plan.md exists (from /gaia-test-design) — flag absence as blocking</action>
-  <action>Record findings as: test_plan_exists: true/false, traceability_complete: true/false, traceability_gate_decision: PASS/BLOCKED/FAIL/NOT_DECLARED, traceability_implementation_rate: {N}%, ci_gates_enforced: true/false</action>
-  <check>If traceability_gate_decision is BLOCKED or FAIL, then traceability_complete MUST be false. Do NOT set traceability_complete: true when the matrix's own gate assessment contradicts this — the matrix is the upstream authority on its own readiness.</check>
-</step>
-<step n="7" title="Security Readiness">
-  <action>Are security requirements documented in PRD?</action>
-  <action>Is authentication/authorization defined in architecture?</action>
-  <action>Are data privacy requirements addressed?</action>
-  <action>Compliance timeline: If PRD or threat-model.md references GDPR, PCI-DSS, HIPAA, or other compliance frameworks, estimate implementation weeks based on related story count and complexity. List each framework with its estimated timeline and the stories that implement it.</action>
-  <action>Priority/schedule conflict: Scan epics-and-stories.md for P0 or P1 compliance-related stories placed in Post-MVP or late-phase epics. Flag each as a WARNING — high-priority compliance work scheduled after MVP creates regulatory risk.</action>
-</step>
-<step n="8" title="Operational Readiness">
-  <action>Rollback: Is a rollback procedure documented in architecture or release plan? Can the deployment be reversed without data loss?</action>
-  <action>Observability: Are logging, metrics, and alerting requirements defined? Are health-check endpoints specified?</action>
-  <action>Release strategy: Is the deployment approach defined (blue-green, canary, rolling)? Does the infrastructure design support it?</action>
-</step>
-<step n="9" title="Brownfield Completeness Check" optional="true" condition="brownfield-onboarding.md exists in {planning_artifacts}">
-  <action>Skip this step if {planning_artifacts}/brownfield-onboarding.md does not exist. This step only applies to brownfield projects.</action>
-  <action>Verify dependency-map.md exists and has: external services, infrastructure, library dependencies, Mermaid graph</action>
-  <action>Verify nfr-assessment.md exists at {test_artifacts}/nfr-assessment.md and has: baseline summary table with real values (not placeholders)</action>
-  <action>If APIs were detected (check project-documentation.md for has_apis flag): verify api-documentation.md exists and has OpenAPI spec and endpoint inventory</action>
-  <action>If events were detected (check project-documentation.md for has_events flag): verify event-catalog.md exists and has produced/consumed event tables</action>
-  <action>If frontend was detected (check project-documentation.md for has_frontend flag): verify ux-design.md exists and has accessibility assessment</action>
-  <action>Verify architecture.md has as-is and target sections with Mermaid diagrams</action>
-  <action>Verify PRD NFR section references nfr-assessment.md baselines (not blank targets)</action>
-  <action>Verify brownfield-onboarding.md links to all generated artifacts</action>
-  <action>Verify {test_artifacts}/dependency-audit-*.md exists — required dependency audit was completed</action>
-</step>
-<step n="10" title="Generate Gate Report">
-  <template-output file="{planning_artifacts}/readiness-report.md">
-    Generate readiness report with YAML frontmatter:
-    ---
-    status: PASS or FAIL or CONDITIONAL PASS
-    date: "{YYYY-MM-DD}"
-    checks_passed: "{N}/8"
-    critical_blockers: {count}
-    completeness: PASS/FAIL
-    completeness_detail:
-      prd_complete: PASS/FAIL
-      ux_complete: PASS/FAIL
-      architecture_complete: PASS/FAIL
-      stories_complete: PASS/FAIL
-    consistency: PASS/FAIL
-    contradictions: PASS/FAIL
-    contradictions_found: {count}
-    contradictions_blocking: {blocking_count}
-    tea_readiness: PASS/FAIL
-    tea_detail:
-      technical: PASS/FAIL
-      estimation: PASS/FAIL
-      architecture: PASS/FAIL
-      testing: PASS/FAIL
-    test_infrastructure: PASS/FAIL
-    test_infrastructure_detail:
-      test_plan_exists: PASS/FAIL
-      traceability_complete: PASS/FAIL
-      traceability_gate_decision: PASS/BLOCKED/FAIL/NOT_DECLARED
-      traceability_implementation_rate: "{N}%"
-      ci_gates_enforced: PASS/FAIL
-    security_readiness: PASS/FAIL
-    operational_readiness: PASS/FAIL
-    operational_detail:
-      rollback_feasible: PASS/FAIL
-      observability_ready: PASS/FAIL
-      release_strategy_defined: PASS/FAIL
-    brownfield_completeness: PASS/FAIL/N/A
-    blocking_issues:
-      - "issue description"
-    ---
-    <check>Before finalizing the report: if traceability_gate_decision is BLOCKED or FAIL and traceability_complete is PASS, this is a self-contradiction. Fix traceability_complete to FAIL and either set status to FAIL, or set status to CONDITIONAL PASS with an explicit justification note (e.g., "Planned test coverage is ~100% but test implementation is {N}% — tests will be implemented during sprint development").</check>
-    Then detailed findings for each gate.
-    Include a "## Contradictions" section listing each detected contradiction:
-    | ID | Type | Source Artifacts | Severity | Authority | Description | Recommended Resolution |
-    If no contradictions found, state "No cross-artifact contradictions detected."
-    If checks were skipped (missing optional artifacts), list them as INFO notes.
-  </template-output>
-</step>
-<step n="11" title="Adversarial Review">
-  <action>Spawn a subagent using the Agent tool: "Load {project-root}/_gaia/core/tasks/review-adversarial.xml. Read its entire contents. Target: {planning_artifacts}/readiness-report.md. Target label: readiness. Follow the task instructions EXACTLY."</action>
-  <action>When subagent returns: verify adversarial-review-readiness-{date}.md exists at {planning_artifacts}/. If the subagent failed to write the file, the orchestrator MUST write it.</action>
-</step>
-<step n="12" title="Incorporate Adversarial Findings">
-  <action>Read the adversarial review report — extract all findings by severity (Critical, High, Medium, Low)</action>
-  <action>For each Critical/High finding: classify as contradiction (data conflicts between artifacts), omission (missing from artifact), misclassification (wrong severity/priority/status), or capacity/feasibility gap. Record which artifact needs to change, what section, and what the correction should be.</action>
-  <action>Update readiness-report.md:
-    - If ANY Critical findings: set status to FAIL
-    - Append a "## Adversarial Review Findings" section with all findings by severity
-    - Append a "## Required Fixes Before Proceeding" section listing each Critical/High finding with: finding ID, source artifact, section to fix, description of required change, responsible agent, and command to run</action>
-  <template-output file="{planning_artifacts}/readiness-report.md">
-    Update readiness report with adversarial findings incorporated, status adjusted if Critical findings exist, and required fixes listed with responsible agents and commands.
-  </template-output>
-</step>
-</workflow>

package/_gaia/lifecycle/workflows/3-solutioning/implementation-readiness/workflow.yaml

@@ -1,48 +0,0 @@
-name: implementation-readiness
-description: 'Validate all artifacts are complete before implementation'
-module: lifecycle
-agent: architect
-config_resolved: "{installed_path}/.resolved/implementation-readiness.yaml"
-config_source: "{project-root}/_gaia/lifecycle/config.yaml"
-installed_path: "{project-root}/_gaia/lifecycle/workflows/3-solutioning/implementation-readiness"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-input_file_patterns:
-  prd:
-    whole: "{planning_artifacts}/prd.md"
-    load_strategy: "FULL_LOAD"
-  ux:
-    whole: "{planning_artifacts}/ux-design.md"
-    load_strategy: "FULL_LOAD"
-  architecture:
-    whole: "{planning_artifacts}/architecture.md"
-    load_strategy: "FULL_LOAD"
-  epics:
-    whole: "{planning_artifacts}/epics-and-stories.md"
-    load_strategy: "FULL_LOAD"
-  traceability:
-    whole: "{test_artifacts}/traceability-matrix.md"
-    load_strategy: "FULL_LOAD"
-  ci_setup:
-    whole: "{test_artifacts}/ci-setup.md"
-    load_strategy: "FULL_LOAD"
-  threat_model:
-    whole: "{planning_artifacts}/threat-model.md"
-    load_strategy: "FULL_LOAD"
-    optional: true
-  infrastructure_design:
-    whole: "{planning_artifacts}/infrastructure-design.md"
-    load_strategy: "FULL_LOAD"
-    optional: true
-quality_gates:
-  pre_start:
-    - check: "traceability_exists"
-      on_fail: "HALT: Run /gaia-trace first — traceability matrix required before readiness check."
-    - check: "ci_setup_exists"
-      on_fail: "HALT: Run /gaia-ci-setup first — CI pipeline config required before readiness check."
-on_error:
-  missing_file: "ask_user"
-  unresolved_variable: "halt"
-
-output:
-  primary: "{planning_artifacts}/readiness-report.md"

package/_gaia/lifecycle/workflows/3-solutioning/infrastructure-design/checklist.md

@@ -1,24 +0,0 @@
----
-title: 'Infrastructure Design Validation'
-validation-target: 'Infrastructure design document'
-required-inputs:
-  - '{planning_artifacts}/architecture.md'
----
-## Environments
-- [ ] Environments defined with purpose and access policy
-- [ ] Environment parity strategy specified
-## Deployment
-- [ ] Container/compute strategy defined
-- [ ] Load balancing and scaling approach specified
-- [ ] Networking design documented
-## IaC
-- [ ] IaC tool selected with rationale
-- [ ] Module structure defined
-- [ ] State management strategy specified
-## Observability
-- [ ] Logging strategy defined
-- [ ] Metrics and dashboards planned
-- [ ] Alerting and escalation policies specified
-## Output Verification
-- [ ] Output file exists at {planning_artifacts}/infrastructure-design.md
-- [ ] Decisions recorded in devops-sidecar

package/_gaia/lifecycle/workflows/3-solutioning/infrastructure-design/instructions.xml

@@ -1,44 +0,0 @@
-<workflow name="infrastructure-design">
-<critical>
-  <mandate>Architecture doc must exist before starting infrastructure design</mandate>
-  <mandate>Record all infrastructure decisions in devops-sidecar</mandate>
-  <mandate>Every environment must have a defined purpose and access policy</mandate>
-</critical>
-<step n="1" title="Load Architecture">
-  <action>Read {planning_artifacts}/architecture.md</action>
-  <action>Extract component inventory, service boundaries, data stores</action>
-  <action>Identify compute, storage, and networking requirements</action>
-</step>
-<step n="2" title="Environment Design">
-  <action>Define environments: dev, staging, production (+ preview if needed)</action>
-  <action>Specify environment parity strategy — how close staging mirrors production</action>
-  <action>Define access policies and promotion gates between environments</action>
-</step>
-<step n="3" title="Deployment Topology">
-  <action>Define container orchestration strategy (Kubernetes, ECS, serverless, etc.)</action>
-  <action>Design service mesh and load balancing approach</action>
-  <action>Specify scaling strategy: horizontal, vertical, auto-scaling triggers</action>
-  <action>Define networking: VPC, subnets, security groups, CDN</action>
-</step>
-<step n="4" title="IaC Structure">
-  <action>Define Infrastructure-as-Code project structure and module design</action>
-  <action>Specify IaC tool and conventions (Terraform, Pulumi, CloudFormation)</action>
-  <action>Design module boundaries matching service boundaries</action>
-  <action>Define state management strategy</action>
-</step>
-<step n="5" title="Observability Plan">
-  <action>Define logging strategy: structured logs, log aggregation, retention</action>
-  <action>Define metrics: application metrics, infrastructure metrics, custom dashboards</action>
-  <action>Define tracing: distributed tracing, correlation IDs</action>
-  <action>Define alerting: SLO-based alerts, escalation policies, on-call rotation</action>
-</step>
-<step n="6" title="Generate Output">
-  <action>Record key decisions in {memory_path}/devops-sidecar/infrastructure-decisions.md</action>
-  <template-output file="{planning_artifacts}/infrastructure-design.md">
-    Generate infrastructure design with: environment matrix, deployment topology, IaC structure, observability plan, and decision rationale.
-  </template-output>
-</step>
-<next-step source="lifecycle-sequence.yaml">
-  <primary command="/gaia-trace">Generate requirements-to-tests traceability matrix</primary>
-</next-step>
-</workflow>

package/_gaia/lifecycle/workflows/3-solutioning/infrastructure-design/workflow.yaml

@@ -1,23 +0,0 @@
-name: infrastructure-design
-description: 'Design deployment topology, IaC structure, and observability plan'
-module: lifecycle
-agent: devops
-config_resolved: "{installed_path}/.resolved/infrastructure-design.yaml"
-config_source: "{project-root}/_gaia/lifecycle/config.yaml"
-installed_path: "{project-root}/_gaia/lifecycle/workflows/3-solutioning/infrastructure-design"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-input_file_patterns:
-  architecture:
-    whole: "{planning_artifacts}/architecture.md"
-    load_strategy: "FULL_LOAD"
-quality_gates:
-  pre_start:
-    - check: "architecture_exists"
-      on_fail: "HALT: Run /gaia-create-arch first — infrastructure design requires architecture doc"
-on_error:
-  missing_file: "ask_user"
-  unresolved_variable: "halt"
-
-output:
-  primary: "{planning_artifacts}/infrastructure-design.md"

package/_gaia/lifecycle/workflows/3-solutioning/security-threat-model/checklist.md

@@ -1,24 +0,0 @@
----
-title: 'Threat Model Validation'
-validation-target: 'Threat model document'
-required-inputs:
-  - '{planning_artifacts}/architecture.md'
----
-## Assets
-- [ ] Assets cataloged with sensitivity levels
-- [ ] Asset locations mapped to components
-## STRIDE Analysis
-- [ ] All six STRIDE categories evaluated per component
-- [ ] Threats are specific and actionable, not generic
-## DREAD Scoring
-- [ ] Each threat scored on all 5 DREAD dimensions
-- [ ] Risk levels assigned (Critical/High/Medium/Low)
-## Mitigations
-- [ ] High and critical threats have mitigations
-- [ ] Mitigations are specific and implementable
-## Security Requirements
-- [ ] Requirements extracted with SR- identifiers
-- [ ] Each requirement has acceptance criteria
-## Output Verification
-- [ ] Output file exists at {planning_artifacts}/threat-model.md
-- [ ] Decisions recorded in security-sidecar

package/_gaia/lifecycle/workflows/3-solutioning/security-threat-model/instructions.xml

@@ -1,55 +0,0 @@
-<workflow name="security-threat-model">
-<critical>
-  <mandate>Architecture doc must exist before starting threat modeling</mandate>
-  <mandate>Use STRIDE methodology for threat identification</mandate>
-  <mandate>Use DREAD scoring for risk prioritization</mandate>
-  <mandate>Record all threat model decisions in security-sidecar</mandate>
-</critical>
-<step n="1" title="Load Architecture">
-  <action>Read {planning_artifacts}/architecture.md</action>
-  <action>Extract system components, data flows, and trust boundaries</action>
-  <action>Identify external interfaces, APIs, and user-facing endpoints</action>
-</step>
-<step n="2" title="Identify Assets">
-  <action>Catalog valuable data and systems: user credentials, PII, financial data, API keys</action>
-  <action>Classify sensitivity: critical, high, medium, low</action>
-  <action>Map asset locations across system components</action>
-</step>
-<step n="3" title="STRIDE Analysis">
-  <action>For each component and data flow, evaluate all six STRIDE categories:</action>
-  <action>Spoofing — Can identities be faked?</action>
-  <action>Tampering — Can data be modified in transit or storage?</action>
-  <action>Repudiation — Can actions be denied without trace?</action>
-  <action>Information Disclosure — Can data leak to unauthorized parties?</action>
-  <action>Denial of Service — Can availability be disrupted?</action>
-  <action>Elevation of Privilege — Can users gain unauthorized access?</action>
-</step>
-<step n="4" title="DREAD Scoring">
-  <action>For each identified threat, rate 1-10 on each DREAD dimension:</action>
-  <action>Damage potential — How severe is the impact?</action>
-  <action>Reproducibility — How easy to reproduce?</action>
-  <action>Exploitability — How much skill/effort to exploit?</action>
-  <action>Affected users — What percentage of users impacted?</action>
-  <action>Discoverability — How easy to find the vulnerability?</action>
-  <action>Calculate average DREAD score and assign risk level: Critical (8-10), High (6-8), Medium (4-6), Low (1-4)</action>
-</step>
-<step n="5" title="Mitigation Strategies">
-  <action>For each high and critical risk threat, propose specific mitigations</action>
-  <action>Map mitigations to implementation: code changes, configuration, infrastructure</action>
-  <action>Prioritize mitigations by risk reduction vs implementation effort</action>
-</step>
-<step n="6" title="Security Requirements">
-  <action>Extract security requirements from threat analysis</action>
-  <action>Format as SR-1, SR-2, etc. with clear acceptance criteria</action>
-  <action>Map requirements to architecture components they protect</action>
-</step>
-<step n="7" title="Generate Output">
-  <action>Record key decisions in {memory_path}/security-sidecar/threat-model-decisions.md</action>
-  <template-output file="{planning_artifacts}/threat-model.md">
-    Generate threat model with: assets table, STRIDE analysis per component, DREAD scores, risk levels, mitigation strategies, and security requirements list.
-  </template-output>
-</step>
-<next-step source="lifecycle-sequence.yaml">
-  <primary command="/gaia-infra-design">Design infrastructure topology and IaC structure</primary>
-</next-step>
-</workflow>

package/_gaia/lifecycle/workflows/3-solutioning/security-threat-model/workflow.yaml

@@ -1,23 +0,0 @@
-name: security-threat-model
-description: 'Create security threat model using STRIDE/DREAD methodology'
-module: lifecycle
-agent: security
-config_resolved: "{installed_path}/.resolved/security-threat-model.yaml"
-config_source: "{project-root}/_gaia/lifecycle/config.yaml"
-installed_path: "{project-root}/_gaia/lifecycle/workflows/3-solutioning/security-threat-model"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-input_file_patterns:
-  architecture:
-    whole: "{planning_artifacts}/architecture.md"
-    load_strategy: "FULL_LOAD"
-quality_gates:
-  pre_start:
-    - check: "architecture_exists"
-      on_fail: "HALT: Run /gaia-create-arch first — threat modeling requires architecture doc"
-on_error:
-  missing_file: "ask_user"
-  unresolved_variable: "halt"
-
-output:
-  primary: "{planning_artifacts}/threat-model.md"

package/_gaia/lifecycle/workflows/4-implementation/action-items/instructions.xml

@@ -1,131 +0,0 @@
-<workflow name="action-items">
-<critical>
-  <mandate>Action items are pre-sprint work — resolve BEFORE sprint planning, not during sprints</mandate>
-  <mandate>Route each item to the correct agent based on type: clarification→assignee agent, implementation→SM, process→user, automation→SM</mandate>
-  <mandate>Every resolution must include reasoning — no silent closures</mandate>
-  <mandate>Items open for 3+ sprints auto-escalate from MEDIUM → HIGH</mandate>
-</critical>
-<step n="1" title="Load and Display">
-  <action>Read {implementation_artifacts}/action-items.yaml</action>
-  <action>If file doesn't exist: display "No action items tracked yet. Action items are created by /gaia-retro, /gaia-triage-findings, /gaia-tech-debt-review, and /gaia-correct-course." and STOP.</action>
-  <action>Filter to open and in-progress items only (skip done/invalid/deferred)</action>
-  <action>Apply escalation: items open for 3+ sprints → auto-escalate MEDIUM → HIGH. Items open for 5+ sprints → flag for mandatory user review.</action>
-  <action>If a specific action_id was provided (e.g., /gaia action A-001): filter to that single item</action>
-  <action>If "status" keyword was provided: display dashboard and STOP (don't process):
-
-    ═══ Action Items Dashboard ═══
-
-    | Status | Count |
-    |--------|-------|
-    | Open | {open_count} |
-    | In Progress | {in_progress_count} |
-    | Done | {done_count} |
-    | Invalid | {invalid_count} |
-    | Deferred | {deferred_count} |
-
-    Open Items by Priority:
-    | ID | Title | Type | Priority | Age (sprints) | Source | Assignee |
-    {for each open item, sorted by priority then age}
-
-    Aged Items (2+ sprints):
-    {list of items open for 2+ sprints with escalation warnings}
-  </action>
-  <action>Display all open items grouped by priority (HIGH first):
-
-    ═══ Action Items: {open_count} open ═══
-
-    | # | ID | Title | Type | Priority | Age | Assignee |
-    {for each open item}
-
-    Processing {count} items...</action>
-</step>
-<step n="2" title="Process Each Item">
-  <action>For each open item (highest priority first, then oldest first):
-
-    Display: "═══ {item.id}: {item.title} ═══"
-    Show: type, priority, source, escalation_count, related_stories, original context from source_ref
-
-    Route based on type:
-
-    **clarification:**
-      If assignee is an agent (e.g., Theo, Derek, Zara):
-        Spawn the assignee agent as a subagent with this prompt:
-        "You are {assignee}. An action item needs your decision:
-        Title: {title}
-        Context: {original context from source_ref}
-        Related stories: {related_stories}
-        This has been open for {escalation_count} sprints.
-        Make a decision: [resolve] with reasoning, [create-story] if implementation needed, or [defer] with justification."
-        Wait for agent to return with decision.
-      If no assignee: ask user who should decide.
-
-    **implementation:**
-      Spawn SM (Nate) as a subagent:
-      "You are Nate (Scrum Master). An action item needs implementation:
-      Title: {title}
-      Context: {original context}
-      Related stories: {related_stories}
-      Decide: [create-story] create a new story for this work, [add-to-existing] add to an existing backlog story, or [already-done] if this was addressed by completed stories."
-      Wait for SM to return with decision.
-      If create-story: spawn /gaia-create-story subagent with the context.
-      If add-to-existing: update the target story's tasks.
-
-    **process:**
-      Present to user directly:
-      "This action item recommends a process change:
-      {title}
-      Context: {original context}
-      Options: [approve] implement the change, [dismiss] not needed, [defer] address later"
-      Wait for user decision.
-
-    **automation:**
-      Route to SM to create an implementation story (same as implementation type).
-
-    In YOLO mode: auto-apply agent/SM recommendations without user confirmation.</action>
-</step>
-<step n="3" title="Update Tracker">
-  <action>For each processed item, update action-items.yaml:
-    - status: done | invalid | deferred | in-progress (based on decision)
-    - resolution: reasoning from the deciding agent/user
-    - resolved_date: current date (for done/invalid)
-    - related_stories: add any newly created story keys
-    - Update last_updated timestamp</action>
-  <action>Save updated action-items.yaml</action>
-  <action>Save to Val memory ({memory_path}/validator-sidecar/decision-log.md):
-    ### [YYYY-MM-DD] Action Items Processed
-
-    - **Agent:** validator
-    - **Workflow:** action-items
-    - **Status:** recorded
-
-    Processed {count} action items.
-    Resolved: {done_count}. Invalid: {invalid_count}. Deferred: {deferred_count}. In Progress: {in_progress_count}.
-    {For each resolved item: "A-{NNN}: {title} → {status} — {brief resolution}"}</action>
-</step>
-<step n="4" title="Summary Report">
-  <action>Display on-screen report (NOT as a file):
-
-    ═══ Action Items Report ═══
-
-    Processed: {processed_count}
-    ✓ Resolved: {done_count}
-    ⊘ Invalid: {invalid_count}
-    → Deferred: {deferred_count}
-    ◎ In Progress: {in_progress_count} (stories created, awaiting sprint)
-    ✗ Remaining: {open_count} (not yet processed)
-
-    | ID | Title | Decision | Reasoning |
-    {for each processed item: id, title, new status, brief resolution}
-
-    {if in_progress_count > 0:}
-    Stories created from action items:
-    {list of new story keys with titles}
-    These will be available in the next /gaia-sprint-plan.
-
-    {if open_count > 0:}
-    {open_count} items remain open. Run /gaia action to continue processing.
-
-    {if all resolved:}
-    All action items resolved. Ready for /gaia-sprint-plan.</action>
-</step>
-</workflow>

package/_gaia/lifecycle/workflows/4-implementation/action-items/workflow.yaml

@@ -1,19 +0,0 @@
-name: action-items
-description: 'Process and resolve action items from retro, triage, tech-debt, and correct-course'
-module: lifecycle
-agent: orchestrator
-template_output_prompt: "auto"
-config_resolved: "{installed_path}/.resolved/action-items.yaml"
-config_source: "{project-root}/_gaia/lifecycle/config.yaml"
-installed_path: "{project-root}/_gaia/lifecycle/workflows/4-implementation/action-items"
-instructions: "{installed_path}/instructions.xml"
-input_file_patterns:
-  action_items:
-    whole: "{implementation_artifacts}/action-items.yaml"
-    load_strategy: "FULL_LOAD"
-on_error:
-  missing_file: "ask_user"
-  unresolved_variable: "halt"
-
-output:
-  primary: "{implementation_artifacts}/action-items.yaml"

package/_gaia/lifecycle/workflows/4-implementation/add-stories/checklist.md

@@ -1,27 +0,0 @@
----
-title: 'Add Stories Validation'
-validation-target: 'Updated epics-and-stories.md'
----
-## Story Protection
-- [ ] Protection map built from sprint-status.yaml
-- [ ] ZERO modifications to locked stories (in-progress, review, ready-for-dev, done)
-- [ ] ZERO modifications to protected stories (invalid)
-- [ ] Any backlog/validating modifications have explicit user confirmation
-- [ ] Protection report displayed to user
-## Epic Creation (if applicable)
-- [ ] New epic ID does not collide with existing
-- [ ] Epic has name, description, goal, success criteria
-- [ ] User confirmed epic assignment
-## Stories
-- [ ] New stories follow existing format exactly
-- [ ] Story IDs do not collide with existing IDs
-- [ ] Each story has acceptance criteria, size, priority
-- [ ] depends_on and blocks declared
-- [ ] No circular dependencies introduced
-- [ ] Risk levels applied (if test-plan.md exists)
-- [ ] Source: CR-{cr_id} added (if change request linked)
-## Change Log
-- [ ] Change log entry added with date, feature name, and CR ID
-## Existing Content
-- [ ] Existing stories not modified
-- [ ] Existing epic structure preserved