gaia-framework 1.57.0 → 1.57.2

package/_gaia/lifecycle/workflows/4-implementation/dev-story/instructions.xml

@@ -1,268 +0,0 @@
-<workflow name="dev-story">
-<critical>
-  <mandate>Story must be in ready-for-dev or in-progress status before starting. Three modes: FRESH (ready-for-dev → new implementation), REWORK (in-progress with failed reviews → fix review issues), RESUME (in-progress with checkpoint or continuing interrupted work)</mandate>
-  <mandate>Follow TDD cycle: red, green, refactor</mandate>
-  <mandate>TDD phases MUST be executed as separate, sequential steps — NEVER combine them. Do NOT write implementation code during the Red phase. Do NOT skip the Refactor phase. Each phase must produce its own checkpoint and wait for user confirmation before the next phase begins.</mandate>
-  <mandate>Write an intermediate checkpoint to {checkpoint_path}/dev-story-{story_key}.yaml after EACH TDD phase completes (Steps 6, 7, 8). Each checkpoint must include: workflow name, current step number, phase status (red_complete/green_complete/refactor_complete), key variables (story_key, epic_key, risk_level), output file path, and files_touched with sha256 checksums (shasum -a 256) for every file created or modified in that phase.</mandate>
-  <mandate>Definition of Done checklist MUST be written to the story file and every item verified before marking complete. The DoD gate (Step 10) auto-fixes failing items up to 3 iterations before halting.</mandate>
-  <mandate>All tests must pass before marking complete</mandate>
-  <mandate>When reading or running application source code, use {project-path} as the base directory — NOT {project-root}. {project-path} is resolved by the engine from global.yaml.</mandate>
-</critical>
-<step n="1" title="Load Story File">
-  <action>Read story .md file, parse YAML frontmatter</action>
-  <action>Extract: key, status, acceptance criteria, subtasks, dependencies</action>
-  <action>Resolve story file path: search {implementation_artifacts}/ for {story_key}-*.md. If no match, try {story_key}.md. Use the resolved path for all subsequent reads and writes.</action>
-</step>
-<step n="2" title="Pre-Start Gate and Mode Detection">
-  <action>Verify story status is 'ready-for-dev' or 'in-progress'</action>
-  <check if="status not in [ready-for-dev, in-progress]">HALT: Story must be in ready-for-dev or in-progress status</check>
-  <action>Detect execution mode based on story state:
-    If status is 'ready-for-dev': set mode=FRESH — new implementation from scratch
-    If status is 'in-progress': determine sub-mode:
-      1. Read story's Review Gate table (if the section exists in the story file)
-      2. If any Review Gate row shows FAILED → set mode=REWORK — review feedback needs to be addressed
-         Display: "Mode: REWORK — review feedback detected. Will focus on fixing review issues."
-      3. Else check for checkpoint at {checkpoint_path}/dev-story-{story_key}.yaml
-         If checkpoint exists → set mode=RESUME — interrupted work
-         Display: "Mode: RESUME — checkpoint found. Will pick up from last phase."
-      4. Else → set mode=RESUME — in-progress but no checkpoint, continue from current state
-         Display: "Mode: RESUME — continuing from current state."</action>
-  <action>Read story frontmatter: extract risk_level field (default: low if absent)</action>
-  <action>Extract epic_key from story_key — e.g., if story_key is "E1-S1", epic_key is "E1" (everything before the last hyphen-and-story-number)</action>
-  <check if="risk_level == high">
-    Search for ATDD file using BOTH patterns (epic-level first, then story-level):
-    1. Epic-level: {test_artifacts}/atdd-{epic_key}*.md (e.g., atdd-E1.md)
-    2. Story-level: {test_artifacts}/atdd-{story_key}*.md (e.g., atdd-E1-S1.md)
-    If EITHER pattern matches a file, the gate PASSES — log which file was found.
-    If NEITHER pattern matches: HALT — This story is marked high-risk. No ATDD file found (searched for atdd-{epic_key}*.md and atdd-{story_key}*.md). Run /gaia-atdd before implementation.
-  </check>
-</step>
-<step n="3" title="Check for WIP">
-  <action>Look for checkpoint file at _memory/checkpoints/dev-story-{story_key}.yaml</action>
-  <check if="checkpoint_exists and has files_touched">Validate checksums (shasum -a 256) for each entry in files_touched — flag DELETED or MODIFIED files, offer Proceed / Start fresh / Review before resuming</check>
-  <check if="checkpoint_exists">Offer to resume from last checkpoint or start fresh</check>
-</step>
-<step n="4" title="Update Status">
-  <action if="mode == FRESH">
-    <invoke-protocol ref="status-sync" story_key="{story_key}" new_status="in-progress" source_workflow="dev-story" />
-  </action>
-  <action if="mode == REWORK or mode == RESUME">Skip status change — story is already in-progress.</action>
-</step>
-<step n="5" title="Plan Implementation">
-  <action if="mode == REWORK">REWORK MODE — Focus plan on fixing review feedback:
-    1. Read the story's Review Gate table — identify which reviews FAILED
-    2. For each FAILED review, read its report file:
-       - Code Review: {implementation_artifacts}/{story_key}-review.md
-       - Security Review: {implementation_artifacts}/{story_key}-security-review.md
-       - QA Tests: {test_artifacts}/{story_key}-qa-tests.md
-       - Test Automation: {test_artifacts}/{story_key}-test-automation.md
-       - Test Review: {test_artifacts}/{story_key}-test-review.md
-       - Performance Review: {implementation_artifacts}/{story_key}-performance-review.md
-    3. Extract specific issues, REQUEST_CHANGES items, and FAILED criteria from each report
-    4. Generate a REWORK plan focused on:
-       - What specific issues each failed review flagged
-       - What code/tests need to change to address each issue
-       - What does NOT need to change (passed reviews — leave alone)
-    5. Present the rework plan. Skip the full implementation plan sections below.
-    6. After presenting: proceed to Step 6 with rework-focused TDD.</action>
-  <action if="mode == RESUME">RESUME MODE — Continue from current state:
-    If checkpoint exists: Step 3 already handled the resume. Proceed from the checkpoint phase.
-    If no checkpoint: re-assess current implementation state and generate a continuation plan focused on remaining work.</action>
-  <action if="mode == FRESH or mode not set">Load relevant sections from {planning_artifacts}/architecture.md — identify architectural components, patterns, and ADRs that apply to this story's scope</action>
-  <action if="mode == FRESH or mode not set">Load relevant sections from {planning_artifacts}/ux-design.md if available — identify UI components, interaction patterns, navigation flows, and accessibility requirements for this story</action>
-  <action if="mode == FRESH or mode not set">Generate a detailed implementation plan with the following mandatory sections:
-
-  **Context** — Why this change is being made: the user need or requirement it addresses, which acceptance criteria it satisfies, and the intended outcome. Reference the story's epic context and how this story fits into the larger feature.
-
-  **Root Cause / Analysis** (if bug fix or refactor) — What is broken or suboptimal and why. For new features, describe the current state (what exists today) vs. the target state (what will exist after implementation).
-
-  **Implementation Steps** — Numbered steps, each with:
-    - Step title describing what it does
-    - File path(s) to create or modify
-    - What specifically changes in each file (new functions, modified logic, added config, etc.)
-    - Why this change is needed (not just what, but the reasoning)
-    - Any relevant ADR or architecture pattern being followed
-    - Dependencies on previous steps (if any)
-
-  **Files to Modify** — Summary table with columns: File | Change | Reason
-    - List every file that will be created, modified, or deleted
-    - Group by: new files, modified files, deleted files
-
-  **Architecture Alignment** — Which ADRs apply to this story and how the implementation follows them. Flag any deviations from architecture with justification.
-
-  **UX Alignment** (if frontend story) — Which screens, components, and interaction patterns from ux-design.md apply. Reference specific wireframes or flow names.
-
-  **Testing Strategy** — How each acceptance criterion will be tested:
-    - Map each AC to at least one test case
-    - Specify test type (unit, integration, e2e) for each
-    - Note any edge cases or boundary conditions to test
-    - Reference ATDD file if this is a high-risk story
-
-  **Risks and Considerations** — Known risks, potential issues, or assumptions the plan depends on. Include:
-    - API contracts that must be maintained
-    - Database migration concerns (if applicable)
-    - Performance implications
-    - Security considerations
-    - Backward compatibility
-
-  **Verification** — How to verify the implementation is correct end-to-end:
-    - Commands to run (build, test, lint)
-    - Manual verification steps if applicable
-    - Expected outputs or behaviors to confirm
-  </action>
-  <action>Present the full plan in a structured, readable format. Use markdown headers for each section and tables where appropriate.</action>
-  <ask>Here is the detailed implementation plan. Review the context, steps, files, testing strategy, and risks. Confirm to proceed, or request changes. [confirm / revise]</ask>
-</step>
-<step n="6" title="TDD Red Phase — Write Failing Tests">
-  <critical>
-    <mandate>RED PHASE ONLY: Write test files ONLY — do NOT write any implementation code in this step. Tests must define expected behavior and FAIL because the implementation does not exist yet.</mandate>
-  </critical>
-  <action>For each subtask: write failing test(s) that define expected behavior (RED)</action>
-  <action>Run the test suite — verify all new tests FAIL</action>
-  <check if="any_new_test_passes">Tests should NOT pass yet — no implementation exists. If a test passes without implementation, it is vacuous and must be rewritten to actually test behavior.</check>
-  <action>Write intermediate checkpoint to {checkpoint_path}/dev-story-{story_key}.yaml with: workflow: dev-story, step: 6, phase: red_complete, story_key, epic_key, risk_level, output_file: {story_key}-tdd-progress.md, files_touched (list every test file created with its sha256 checksum via shasum -a 256)</action>
-  <action>Print a formatted summary directly in the conversation so the user can review without opening the file:
-
-  ## RED Phase Complete
-
-  **Tests created:**
-  {bulleted list of each test file: file path, test name, what acceptance criterion or behavior it validates}
-
-  **Test runner output:**
-  ```
-  {paste the actual terminal output from the test runner showing all failures}
-  ```
-
-  **Status:** All {count} new tests FAILING as expected
-  </action>
-  <template-output file="{implementation_artifacts}/{story_key}-tdd-progress.md">
-    RED phase complete. Summary: test files created, test names, what each validates, confirmation all new tests fail. Include test runner output showing failures.
-  </template-output>
-  <action if="yolo_mode">Val auto-validates this TDD output (per val_auto_in_yolo). If Val returns CRITICAL/WARNING findings: auto-fix them, re-invoke Val, repeat up to 3 times. HALT if unresolved. Save all findings and fixes to validator-sidecar memory.</action>
-  <ask>Red phase complete — tests written and all failing as expected. Review test output above. [proceed to Green phase / revise tests]</ask>
-</step>
-<step n="7" title="TDD Green Phase — Implement to Pass">
-  <critical>
-    <mandate>GREEN PHASE: Write the MINIMUM implementation code needed to make failing tests pass. Do NOT write final/polished code — that is for the Refactor phase.</mandate>
-  </critical>
-  <check if="red_phase_not_complete">HALT: Red phase template-output must be saved before starting Green phase. Complete Step 6 first.</check>
-  <action>For each subtask: implement minimum code to make failing tests pass (GREEN)</action>
-  <action>Run the test suite — verify all tests PASS</action>
-  <check if="any_test_fails">HALT: All tests must pass before proceeding. Fix failing tests or implementation.</check>
-  <action>Mark each completed subtask in story file</action>
-  <action>Conditional checks — for each that applies:
-    — If API boundary changes: write or update contract tests (consumer/provider)
-    — If database schema changes: create reversible migration script (UP + DOWN)
-    — If gradual rollout needed: implement feature flag wrapping new code path</action>
-  <action>Write intermediate checkpoint to {checkpoint_path}/dev-story-{story_key}.yaml with: workflow: dev-story, step: 7, phase: green_complete, story_key, epic_key, risk_level, output_file: {story_key}-tdd-progress.md, files_touched (list every implementation file created/modified with its sha256 checksum via shasum -a 256)</action>
-  <action>Print a formatted summary directly in the conversation so the user can review without opening the file:
-
-  ## GREEN Phase Complete
-
-  **Files created/modified:**
-  {bulleted list: file path + what was added/changed in each}
-
-  **Contract tests / migrations (if applicable):**
-  {list any contract tests or DB migration scripts created, or "N/A"}
-
-  **Test runner output:**
-  ```
-  {paste the actual terminal output from the test runner showing all tests passing}
-  ```
-
-  **Status:** All {count} tests PASSING with minimal implementation
-  </action>
-  <template-output file="{implementation_artifacts}/{story_key}-tdd-progress.md">
-    GREEN phase complete. Summary: files created/modified, all tests passing, any contract tests or migrations created. Include test runner output showing all green.
-  </template-output>
-  <action if="yolo_mode">Val auto-validates this TDD output (per val_auto_in_yolo). If Val returns CRITICAL/WARNING findings: auto-fix them, re-invoke Val, repeat up to 3 times. HALT if unresolved. Save all findings and fixes to validator-sidecar memory.</action>
-  <ask>Green phase complete — all tests passing with minimal implementation. Review implementation above. [proceed to Refactor phase / revise implementation]</ask>
-</step>
-<step n="8" title="TDD Refactor Phase">
-  <critical>
-    <mandate>REFACTOR PHASE: Improve code quality, extract abstractions, decompose components, improve naming. Do NOT skip this step even if the Green phase code looks acceptable.</mandate>
-  </critical>
-  <check if="green_phase_not_complete">HALT: Green phase template-output must be saved before starting Refactor phase. Complete Step 7 first.</check>
-  <action>Refactor implementation while keeping all tests green: extract shared utilities, decompose large functions, improve naming, remove duplication</action>
-  <action>Run the test suite — verify all tests still PASS after refactoring</action>
-  <check if="any_test_fails">HALT: Refactoring broke tests. Revert or fix before proceeding.</check>
-  <action>Write intermediate checkpoint to {checkpoint_path}/dev-story-{story_key}.yaml with: workflow: dev-story, step: 8, phase: refactor_complete, story_key, epic_key, risk_level, output_file: {story_key}-tdd-progress.md, files_touched (list ALL files created/modified across all 3 phases with sha256 checksums via shasum -a 256)</action>
-  <action>Print a formatted summary directly in the conversation so the user can review without opening the file:
-
-  ## REFACTOR Phase Complete
-
-  **What was refactored:**
-  {bulleted list: what changed and why — extracted utilities, decomposed functions, improved naming, removed duplication}
-
-  **Test runner output:**
-  ```
-  {paste the actual terminal output from the test runner confirming all tests still pass}
-  ```
-
-  **Status:** All {count} tests STILL PASSING after refactor
-  </action>
-  <template-output file="{implementation_artifacts}/{story_key}-tdd-progress.md">
-    REFACTOR phase complete. Summary: what was refactored, why, confirmation all tests still pass. Include test runner output.
-  </template-output>
-  <action if="yolo_mode">Val auto-validates this TDD output (per val_auto_in_yolo). If Val returns CRITICAL/WARNING findings: auto-fix them, re-invoke Val, repeat up to 3 times. HALT if unresolved. Save all findings and fixes to validator-sidecar memory.</action>
-  <ask>Refactor phase complete — all tests still passing. Review refactored code. [proceed / continue refactoring]</ask>
-</step>
-<step n="9" title="Capture Findings">
-  <action>Review any out-of-scope issues discovered during implementation (e.g., missing setup scripts, environment gaps, tech debt, broken tooling)</action>
-  <action>For each finding: add a row to the Findings table in the story file with type, severity, finding description, and suggested action</action>
-  <action>If no findings were discovered, leave the Findings table empty</action>
-</step>
-<step n="10" title="Definition of Done Verification">
-  <action>Write or update the "Definition of Done" section in the story file with the following checklist items. For each item, run the verification described and mark it [x] if it passes or [ ] if it fails:</action>
-  <action>- [ ] **Code compiles** — run the project build command (e.g., npm run build, mvn compile, flutter build). Mark [x] if exit code 0, [ ] if errors.</action>
-  <action>- [ ] **All tests pass** — run the full test suite. Mark [x] if all tests pass, [ ] if any fail.</action>
-  <action>- [ ] **All acceptance criteria met** — compare each AC from the story against the implementation. Mark [x] only if every AC is demonstrably satisfied.</action>
-  <action>- [ ] **No linting/formatting errors** — run the project linter (e.g., eslint, pylint, dart analyze). Mark [x] if no errors, [ ] if errors found.</action>
-  <action>- [ ] **Code follows project conventions** — verify naming, file structure, and patterns match existing codebase. Mark [x] if consistent.</action>
-  <action>- [ ] **No hardcoded secrets or credentials** — scan new/modified files for API keys, passwords, tokens, connection strings. Mark [x] if clean.</action>
-  <action>- [ ] **All subtasks marked complete** — verify every subtask in the story file is checked off. Mark [x] if all done.</action>
-  <action>- [ ] **Documentation updated** — if the change affects APIs, configs, or user-facing behavior, verify that relevant docs are updated. Mark [x] if not applicable or if docs are updated.</action>
-  <action>AUTO-FIX LOOP: After running all checks, if any item is marked [ ] (failing):
-    1. Identify each failing item and the specific issue causing it to fail
-    2. Auto-fix the issue (fix lint errors, fix failing tests, update docs, complete missed subtasks, remove hardcoded secrets, etc.)
-    3. Re-run ALL 8 DoD checks from the top and update the checklist in the story file
-    4. Repeat steps 1-3 up to a maximum of 3 fix iterations
-    5. If all 8 items pass (all marked [x]) at any point: auto-proceed to Step 11 — no user prompt needed
-    6. If items still fail after 3 iterations: HALT with a clear list of unresolved items</action>
-  <check if="dod_unresolved_after_3_attempts">HALT: Could not resolve all Definition of Done items after 3 auto-fix attempts. Unresolved: {list of failing items with reasons}. Manual intervention required.</check>
-</step>
-<step n="11" title="Load Skills JIT">
-  <action>Load git-workflow:commits section for commit conventions</action>
-  <action>Apply conventional commit format to all commits</action>
-</step>
-<step n="12" title="Commit Changes">
-  <action>Stage all changes</action>
-  <action>Commit with conventional commit format: type(scope): description</action>
-</step>
-<step n="13" title="Post-Complete Gate">
-  <action>Verify all tests pass (final confirmation)</action>
-  <action>Verify all acceptance criteria met</action>
-  <action>Verify all subtasks marked complete</action>
-  <action>Re-read the "Definition of Done" section from the story file — verify every item is checked (- [x]). Required items: code compiles, all tests pass, acceptance criteria met, no lint errors, project conventions followed, no hardcoded secrets, all subtasks complete, documentation updated.</action>
-  <check if="any_test_fails">HALT: All tests must pass before marking complete</check>
-  <check if="any_dod_unchecked">HALT: All Definition of Done items must be checked before moving to review. Unchecked items: {list}. Return to Step 10 to resolve.</check>
-</step>
-<step n="14" title="Update Status">
-  <invoke-protocol ref="status-sync" story_key="{story_key}" new_status="review" source_workflow="dev-story" />
-  <action>Append files changed list to story file</action>
-  <action>Initialize Review Gate section in story file: set all six rows (Code Review, QA Tests, Security Review, Test Automation, Test Review, Performance Review) to PENDING with report link "—". If Review Gate section already exists, reset all rows to PENDING.</action>
-  <template-output file="{implementation_artifacts}/{story_key}-*.md">
-    Update story file with status change to 'review', list of files changed, and initialized Review Gate table (all 6 rows PENDING).
-  </template-output>
-</step>
-<step n="15" title="Auto-Run Reviews (YOLO only)">
-  <action if="not yolo_mode">Skip this step — in normal mode, user runs /gaia-run-all-reviews manually when ready.</action>
-  <action if="yolo_mode">Spawn a subagent using the Agent tool with this prompt:
-    "Load {project-root}/_gaia/core/engine/workflow.xml, then process {project-root}/_gaia/lifecycle/workflows/4-implementation/run-all-reviews/workflow.yaml as workflow-config. The story key is {story_key}. Run in YOLO mode — auto-proceed past all template-outputs. Follow the workflow engine instructions EXACTLY."
-  </action>
-  <action if="yolo_mode">When subagent returns: read the story file, parse the Review Gate table.
-    - If ALL 6 reviews PASSED: report "All reviews passed. Story {story_key} is ready for done status."
-    - If any review FAILED: report "{N} review(s) failed: {list of failed reviews}. Story moved to in-progress. Fix issues and re-run /gaia-run-all-reviews."
-  </action>
-</step>
-</workflow>

package/_gaia/lifecycle/workflows/4-implementation/dev-story/workflow.yaml

@@ -1,51 +0,0 @@
-name: dev-story
-description: 'Execute story implementation following story spec'
-module: lifecycle
-agent: dev-*
-execution_mode: planning
-val_auto_in_yolo: true
-val_auto_in_yolo_steps: [5, 6, 7, 8]
-agent_auto_detect: true
-agent_auto_detect_strategy: |
-  1. Read story file frontmatter for tech_stack or stack field — map to agent (typescript→typescript-dev, angular→angular-dev, flutter→flutter-dev, java→java-dev, python→python-dev, mobile→mobile-dev, go→go-dev)
-  2. If absent: read {planning_artifacts}/architecture.md for primary language/framework
-  3. If ambiguous: check file extensions in story subtasks (.ts/.tsx→typescript, .dart→flutter, .java→java, .py→python, .swift/.kt→mobile, .component.ts→angular, .go→go)
-  4. Fallback: ask user which developer to use
-config_resolved: "{installed_path}/.resolved/dev-story.yaml"
-config_source: "{project-root}/_gaia/lifecycle/config.yaml"
-installed_path: "{project-root}/_gaia/lifecycle/workflows/4-implementation/dev-story"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-required_skills:
-  - "{project-root}/_gaia/dev/skills/git-workflow.md"
-  - "{project-root}/_gaia/dev/skills/testing-patterns.md"
-required_skill_sections:
-  - "git-workflow:commits"
-  - "git-workflow:pull-requests"
-  - "testing-patterns:tdd-cycle"
-quality_gates:
-  pre_start:
-    - check: "story_file_exists({implementation_artifacts}/{story_key}-*.md)"
-      on_fail: "HALT: Story file not found. Expected {implementation_artifacts}/{story_key}-*.md. Run /gaia-create-story first."
-    - check: "story_status in ['ready-for-dev', 'in-progress']"
-      on_fail: "HALT: Story must be in ready-for-dev or in-progress status."
-  post_complete:
-    - check: "all_tests_pass == true"
-      on_fail: "HALT: All tests must pass before marking complete. Run test suite in {project-path}/ and fix failing tests."
-input_file_patterns:
-  story:
-    whole: "{implementation_artifacts}/{{story_key}}-*.md"
-    load_strategy: "FULL_LOAD"
-  architecture:
-    whole: "{planning_artifacts}/architecture.md"
-    load_strategy: "INDEX_GUIDED"
-  ux_design:
-    whole: "{planning_artifacts}/ux-design.md"
-    load_strategy: "INDEX_GUIDED"
-on_error:
-  missing_file: "ask_user"
-  unresolved_variable: "halt"
-story_statuses: [backlog, validating, ready-for-dev, in-progress, invalid, review, done]
-
-output:
-  primary: "{implementation_artifacts}/{story_key}-*.md"

package/_gaia/lifecycle/workflows/4-implementation/epic-status/checklist.md

@@ -1,25 +0,0 @@
----
-title: 'Epic Status Dashboard Validation'
-validation-target: 'Epic status dashboard output'
----
-## Completeness
-- [ ] All epics from epics-and-stories.md are represented
-- [ ] All stories per epic are accounted for
-- [ ] Stories with no file are listed as backlog
-
-## Accuracy
-- [ ] Story counts per epic are correct
-- [ ] Done counts match stories with status: done
-- [ ] Completion percentages are mathematically correct (done/total * 100)
-
-## Display
-- [ ] Summary table shows all epics with counts and percentages
-- [ ] Per-epic detail sections include ASCII progress bars
-- [ ] Per-epic story tables show key, title, status, sprint
-- [ ] Completed epics are marked with [COMPLETE]
-- [ ] Untracked stories section is present (even if empty)
-- [ ] Legend section is present
-
-## Output
-- [ ] File written to {implementation_artifacts}/epic-status.md
-- [ ] File uses the epic-status-template.md structure

package/_gaia/lifecycle/workflows/4-implementation/epic-status/instructions.xml

@@ -1,62 +0,0 @@
-<workflow name="epic-status">
-<critical>
-  <mandate>Read ONLY frontmatter from story files — never load full story content (token budget protection)</mandate>
-  <mandate>Stories with no .md file are counted as backlog status</mandate>
-  <mandate>Cross-sprint aggregation — do NOT filter by current sprint</mandate>
-  <mandate>Story files with an epic field in frontmatter belong to that epic — even if not listed in epics-and-stories.md</mandate>
-</critical>
-<step n="1" title="Load Epics Manifest">
-  <action>Read {planning_artifacts}/epics-and-stories.md</action>
-  <action>Parse all epics: extract epic number, title, goal, done criteria</action>
-  <action>Extract all story keys associated with each epic</action>
-  <action>Build epic-to-stories mapping</action>
-</step>
-<step n="2" title="Scan Story Data">
-  <action>ALWAYS scan all .md files in {implementation_artifacts}/ for story files:
-    For each file, read ONLY the YAML frontmatter (stop at closing ---)
-    Extract: story key, title, status, sprint_id (if present), epic, author
-    Skip non-story files (e.g., sprint-status.yaml, epic-status.md, tech-debt-dashboard.md, sprint-plan.md, story-index.yaml, retro-*.md, sprint-reconciliation-*.md)
-    The story file frontmatter is ALWAYS the source of truth for status — never rely solely on story-index.yaml which may be incomplete.</action>
-  <action>If {implementation_artifacts}/story-index.yaml exists: use it as a supplementary source for stories that have no .md file (e.g., stories listed in epics-and-stories.md but with no file yet). Do NOT use it as a replacement for scanning actual story files.</action>
-</step>
-<step n="3" title="Aggregate Status">
-  <action>Join scanned story data to epic-story mapping from Step 1</action>
-  <action>For stories found in Step 2 that are NOT in the Step 1 epic-story mapping:
-    1. Read the story's epic field (from index or frontmatter, e.g., "E9 — Enhanced Agent Memory")
-    2. Extract the epic key (e.g., "E9")
-    3. If the epic key matches an existing epic from Step 1: add this story to that epic's story list
-    4. Do NOT put it in "untracked" if it has a valid epic key
-    5. Only stories with NO epic field go to "untracked"</action>
-  <action>For each story, resolve the display title using this priority:
-    1. Story file frontmatter title (from Step 2) — primary source, always preferred
-    2. Title from epics-and-stories.md (from Step 1) — fallback if no story file exists
-    3. If neither available: show "(no title)" with the story key
-    If the story was created by triage (author field contains "Triage"): append " ⚑" flag after the title to indicate triage origin</action>
-  <action>Stories in manifest but with no file and no index entry: mark as backlog</action>
-  <action>Per epic: count done, in-progress, invalid, review, ready-for-dev, validating, backlog</action>
-  <action>Per epic: compute completion percentage (done / total * 100)</action>
-  <action>Compute overall totals across all epics</action>
-  <action>Collect any story files found that are NOT in any epic (no epic field) as untracked</action>
-  <action>Mark epics where all stories are done as [COMPLETE]</action>
-</step>
-<step n="4" title="Dependency Analysis">
-  <action>For each story scanned in Step 2: check frontmatter for `dependencies` or `blocked_by` fields (list of story keys this story depends on)</action>
-  <action>Build cross-epic dependency graph: for each dependency, check if the depended-on story belongs to a different epic. Record cross-epic edges.</action>
-  <action>Identify blocked stories: stories whose dependencies include stories that are NOT yet `done`. List each blocked story with its blocker(s) and blocker status.</action>
-  <action>Calculate critical path: find the longest chain of sequential dependent stories across all epics. Report the chain and its total length.</action>
-  <action>If no story files contain dependency metadata: note "No dependency data available — add `dependencies` field to story frontmatter for cross-epic tracking." Skip blocked story and critical path calculations.</action>
-</step>
-<step n="5" title="Generate Dashboard">
-  <action>Format dashboard with standard header: "## Epic Status Dashboard — {date}" followed by summary line: "Epics: {complete}/{total} complete | Stories: {done}/{total} ({pct}%) | At Risk: {blocked_count}"</action>
-  <action>Load template from {project-root}/_gaia/lifecycle/templates/epic-status-template.md</action>
-  <action>Fill summary table with per-epic row: Total | Done | In Progress | Review | Blocked | Backlog | Completion %. Backlog = stories not yet started (no file, or status is backlog/ready-for-dev/validating). Do NOT use "Remaining" (total - done) as it overlaps with In Progress.</action>
-  <action>Fill per-epic detail sections with ASCII progress bar and story-level status table</action>
-  <action>ASCII progress bar: use filled blocks (█) for done, light blocks (░) for remaining, 20 chars wide</action>
-  <action>Fill untracked stories section</action>
-  <action>Fill dependency analysis section: cross-epic dependencies table (source story → target story → target epic → target status), blocked stories list with blockers, and critical path summary. If no dependency data, include the "no data" note from Step 4.</action>
-  <template-output file="{implementation_artifacts}/epic-status.md">
-    Write the completed epic status dashboard using the template.
-    Include all epics, all stories, completion percentages, progress bars, and dependency analysis.
-  </template-output>
-</step>
-</workflow>

package/_gaia/lifecycle/workflows/4-implementation/epic-status/workflow.yaml

@@ -1,24 +0,0 @@
-name: epic-status
-description: 'Show epic completion dashboard across all sprints'
-module: lifecycle
-agent: sm
-template_output_prompt: "auto"
-config_resolved: "{installed_path}/.resolved/epic-status.yaml"
-config_source: "{project-root}/_gaia/lifecycle/config.yaml"
-installed_path: "{project-root}/_gaia/lifecycle/workflows/4-implementation/epic-status"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-template: "{project-root}/_gaia/lifecycle/templates/epic-status-template.md"
-input_file_patterns:
-  epics:
-    whole: "{planning_artifacts}/epics-and-stories.md"
-    load_strategy: "FULL_LOAD"
-  stories:
-    pattern: "{implementation_artifacts}/*.md"
-    load_strategy: "FRONTMATTER_ONLY"
-on_error:
-  missing_file: "ask_user"
-  unresolved_variable: "halt"
-
-output:
-  primary: "{implementation_artifacts}/epic-status.md"

package/_gaia/lifecycle/workflows/4-implementation/fix-story/checklist.md

@@ -1,12 +0,0 @@
----
-title: 'Story Fix Check'
-validation-target: 'Story fix after validation'
----
-## Checks
-- [ ] All FAIL findings from validation report addressed
-- [ ] Existing valid content preserved (PASS sections unchanged)
-- [ ] Story follows template structure
-- [ ] Old validation report removed from end of file
-- [ ] No new issues introduced
-- [ ] Corrected story file saved
-- [ ] sprint-status.yaml updated with story status as validating

package/_gaia/lifecycle/workflows/4-implementation/fix-story/instructions.xml

@@ -1,67 +0,0 @@
-<workflow name="fix-story">
-<critical>
-  <mandate>Fix all FAIL findings from the validation report</mandate>
-  <mandate>Preserve all existing valid content — only modify sections flagged as FAIL</mandate>
-  <mandate>Remove the old validation report after fixes are applied</mandate>
-</critical>
-<step n="1" title="Load Story">
-  <ask>Which story to fix? (provide story key, e.g., 1.2)</ask>
-  <action>Find and read the story file matching {story_key}-*.md in {implementation_artifacts}/</action>
-</step>
-<step n="2" title="Parse Validation Report">
-  <action>Locate the "## Validation Report" section at the end of the story file (after the --- separator)</action>
-  <action>Extract all FAIL findings with their section names and issue descriptions</action>
-  <check if="no_validation_report">If no validation report is found, HALT and instruct the user to run /gaia-validate-story first</check>
-  <check if="all_pass">If all sections are PASS, inform user the story has no issues to fix and STOP</check>
-</step>
-<step n="3" title="Load Template Reference">
-  <action>Read the story template from {project-root}/_gaia/lifecycle/templates/story-template.md</action>
-  <action>Use the template as reference for expected structure and format of each section</action>
-</step>
-<step n="4" title="Fix Flagged Issues">
-  <action>For each FAIL finding, prepare the proposed fix:
-    - Missing sections: draft the section following the template structure
-    - Incomplete metadata: draft missing YAML frontmatter fields. Required fields: key, title, epic, status, priority, size, points, risk, sprint_id, depends_on, blocks, traces_to, date, author
-    - Unclear ACs: draft rewrite in Given/When/Then format, ensure each is testable
-    - Unlinked subtasks: draft links from each subtask to an AC number
-    - Empty Test Scenarios: draft the test scenarios table
-    - Missing DoD: draft specific, measurable Definition of Done items
-    - Other issues: draft fix per the validation finding description
-  </action>
-  <ask>For each proposed fix, present the section name, the issue found, and the proposed new content. Wait for user approval before applying. Example: "Section: Acceptance Criteria — Issue: Not in Given/When/Then format — Proposed fix: [content]. Apply this fix? (yes / no / edit)"</ask>
-  <action>Apply only user-approved fixes. If user chooses "edit", accept their revised content instead.</action>
-  <action>Preserve all existing valid content — do NOT rewrite sections that passed validation</action>
-</step>
-<step n="4b" title="Change Log">
-  <action>After all fixes are applied, append a "## Change Log" section at the end of the story file (before any validation report) with:
-    - Date: {current date}
-    - Source: fix-story workflow
-    - Sections modified: list each section that was fixed
-    - Summary: one-line description of changes made
-  </action>
-</step>
-<step n="5" title="Remove Validation Report">
-  <action>Remove the --- separator and the entire "## Validation Report" section from the end of the story</action>
-</step>
-<step n="5b" title="Re-Validate">
-  <action>Run inline validation checks on the corrected story (same criteria as /gaia-validate-story Steps 2-6):
-    - YAML frontmatter: verify all 14 required fields present (key, title, epic, status, priority, size, points, risk, sprint_id, depends_on, blocks, traces_to, date, author)
-    - Completeness: verify all sections present (User Story, AC, Tasks, Dev Notes, Technical Notes, Dependencies, Test Scenarios, Project Structure Notes, References, Dev Agent Record, Estimate, DoD)
-    - Clarity: verify ACs are in Given/When/Then format, subtasks linked to AC numbers, DoD items are measurable
-    - Dependencies: verify declared dependencies exist and are resolvable
-  </action>
-  <check if="all_checks_pass">
-    <invoke-protocol ref="status-sync" story_key="{story_key}" new_status="ready-for-dev" source_workflow="fix-story" />
-    Inform user "Story {story_key} passed re-validation and is now ready for development."
-  </check>
-  <check if="issues_remain">
-    <invoke-protocol ref="status-sync" story_key="{story_key}" new_status="validating" source_workflow="fix-story" />
-    List remaining issues and inform user: "Some issues remain after fixes — run /gaia-fix-story again or manually edit, then /gaia-validate-story."
-  </check>
-</step>
-<step n="6" title="Save Corrected Story">
-  <template-output file="{implementation_artifacts}/{story_key}-{story_title_slug}.md">
-    Save the corrected story file with all FAIL issues resolved and the old validation report removed. If re-validation passed, status is ready-for-dev. If issues remain, status stays validating.
-  </template-output>
-</step>
-</workflow>

package/_gaia/lifecycle/workflows/4-implementation/fix-story/workflow.yaml

@@ -1,17 +0,0 @@
-name: fix-story
-description: 'Fix story issues flagged by validation'
-module: lifecycle
-agent: sm
-config_resolved: "{installed_path}/.resolved/fix-story.yaml"
-config_source: "{project-root}/_gaia/lifecycle/config.yaml"
-installed_path: "{project-root}/_gaia/lifecycle/workflows/4-implementation/fix-story"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-template: "{project-root}/_gaia/lifecycle/templates/story-template.md"
-on_error:
-  missing_file: "ask_user"
-  unresolved_variable: "halt"
-
-output:
-  primary: "{implementation_artifacts}/{story_key}-{story_title_slug}.md"
-  secondary: "{implementation_artifacts}/sprint-status.yaml"

package/_gaia/lifecycle/workflows/4-implementation/qa-generate-tests/checklist.md

@@ -1,19 +0,0 @@
----
-title: 'QA Test Generation Validation'
-validation-target: 'Generated tests'
----
-## Tests
-- [ ] API tests generated
-- [ ] E2E tests generated
-- [ ] Tests pass on first run
-## Coverage
-- [ ] All acceptance criteria covered
-## Verdict
-- [ ] PASSED or FAILED verdict clearly stated in report
-## Review Gate
-- [ ] Review Gate table updated in story file
-- [ ] If PASSED: QA Tests row shows PASSED with report link
-- [ ] If FAILED: QA Tests row shows FAILED, story status set to in-progress
-- [ ] Review gate check protocol invoked
-## Output Verification
-- [ ] Test report exists at {test_artifacts}/{story_key}-qa-tests.md

package/_gaia/lifecycle/workflows/4-implementation/qa-generate-tests/instructions.xml

@@ -1,52 +0,0 @@
-<workflow name="qa-generate-tests">
-<critical>
-  <mandate>Story must be in review status before QA testing</mandate>
-  <mandate>Do NOT write executable test files to the source tree (tests/, spec/, __tests__/, e2e/). Document test cases in the QA report only, written to {test_artifacts}/.</mandate>
-  <mandate>Output must include machine-readable PASSED or FAILED verdict</mandate>
-  <mandate>When reading or running application source code, use {project-path} as the base directory — NOT {project-root}. {project-path} is resolved by the engine from global.yaml.</mandate>
-</critical>
-<step n="1" title="Load Story and Code">
-  <action>Resolve story file: search for {story_key}-*.md in {implementation_artifacts}/ using glob pattern to match the full filename ({story_key}-{title_slug}.md)</action>
-  <action>Read story acceptance criteria</action>
-  <action>Read implemented code files</action>
-</step>
-<step n="2" title="Status Gate">
-  <action>Verify story is in 'review' status</action>
-  <check if="status != review">HALT: Story must be in review status before QA testing</check>
-</step>
-<step n="3" title="API Test Case Documentation">
-  <action>Document API/integration test cases for endpoints — do NOT write executable test files</action>
-  <action>For each test case: describe endpoint, method, input, expected response, and edge cases</action>
-  <action>Cover happy path, error cases, boundary conditions, and authorization scenarios</action>
-  <action>Use test case IDs in format TC-{story_key}-{NNN} (e.g., TC-E1-S1-001). Include fields: ID, AC reference, Preconditions, Steps, Expected Result.</action>
-</step>
-<step n="4" title="E2E Test Case Documentation">
-  <action>Document end-to-end test scenarios from user journeys — do NOT write executable test files</action>
-  <action>For each scenario: describe preconditions, user actions, assertions, and cleanup</action>
-  <action>Continue TC-{story_key}-{NNN} numbering sequence from Step 3</action>
-</step>
-<step n="5" title="Test Execution">
-  <action>If executable tests already exist in the source tree for this story: run them and report results</action>
-  <action>If no existing tests: run the application and manually verify key acceptance criteria through API calls or UI inspection</action>
-  <action>Do NOT create new test files in the source tree — test file creation is the responsibility of /gaia-test-automate</action>
-</step>
-<step n="6" title="Verdict">
-  <action>If ALL tests pass: verdict is PASSED</action>
-  <action>If ANY test fails: verdict is FAILED — list failing tests with reasons</action>
-</step>
-<step n="7" title="Generate Output">
-  <template-output file="{test_artifacts}/{story_key}-qa-tests.md">
-    Generate QA test report with test files created, execution results, and machine-readable verdict (PASSED/FAILED).
-  </template-output>
-</step>
-<step n="8" title="Update Review Gate and Transition">
-  <action>Read story file, locate Review Gate table</action>
-  <action>If PASSED: update QA Tests row status to PASSED, link report file</action>
-  <action>If FAILED: update QA Tests row status to FAILED, link report file. Do NOT change story status — the review-gate-check protocol or run-all-reviews orchestrator handles status transitions.</action>
-  <template-output file="{implementation_artifacts}/{story_key}-*.md">
-    Update story file Review Gate table with QA test result and report link.
-  </template-output>
-  <action>Inform user: "Note: sprint-status.yaml may now be out of sync. Run /gaia-sprint-status to reconcile."</action>
-  <invoke-protocol name="review-gate-check" file="{project-root}/_gaia/core/protocols/review-gate-check.xml" />
-</step>
-</workflow>