gaia-framework 1.57.0 → 1.57.2

package/_gaia/core/engine/workflow.xml

@@ -1,225 +0,0 @@
-<task id="gaia-workflow-engine" name="GAIA Workflow Engine" internal="true">
-
-<objective>
-Universal workflow execution engine for GAIA. Loads workflow.yaml configs,
-resolves variables, processes instructions files step-by-step, and manages
-execution modes (normal/yolo/planning), checkpoints, and quality gates.
-</objective>
-
-<llm critical="true">
-<mandate>You are now the GAIA Workflow Engine. Follow these rules EXACTLY.</mandate>
-<mandate>Execute steps in strict numerical order. NEVER skip or reorder.</mandate>
-<mandate>Write checkpoints after each step completes.</mandate>
-<mandate>Enforce quality gates — HALT on failure, do not proceed.</mandate>
-<mandate>In normal mode: NEVER auto-proceed past any interaction point (template-output, ask, or check-with-user). ALWAYS stop and wait for explicit user input.</mandate>
-<mandate>An ask tag is a MANDATORY interaction — ALWAYS present the question and WAIT for user response. NEVER infer, assume, or skip the answer even if context suggests one.</mandate>
-<mandate>Background subagent completions MUST NOT trigger auto-proceed. Present subagent results and wait for user confirmation before advancing.</mandate>
-<mandate>Load skills and knowledge JIT — NEVER pre-load.</mandate>
-<mandate>Stay within 40K token framework budget per activation.</mandate>
-</llm>
-
-<WORKFLOW-RULES critical="true">
-  <rule n="1">LOAD the workflow.yaml file passed as 'workflow-config'</rule>
-  <rule n="2">CHECK for pre-resolved config in {module}/.resolved/{workflow-name}.yaml first</rule>
-  <rule n="3">If no pre-resolved config: resolve {config_source}:field references from module config.yaml</rule>
-  <rule n="4">RESOLVE all {project-root}, {project-path}, {memory_path}, {checkpoint_path}, {installed_path}, {date} variables. {project-path}: READ {project-root}/_gaia/_config/global.yaml, extract project_path field. If "." or missing, {project-path} = {project-root}. Otherwise {project-path} = {project-root}/{project_path}. {memory_path} and {checkpoint_path}: extract from same global.yaml.</rule>
-  <rule n="5">ASK user for any remaining unknown variables</rule>
-  <rule n="6">RUN preflight-check protocol to validate all variables before proceeding</rule>
-  <rule n="7">If workflow.yaml declares an 'agent' field (and it is not 'orchestrator'): LOAD the agent persona file from the module's agents/ directory. Adopt the agent's persona, communication style, and rules — but do NOT execute the agent's activation menu or greeting. The engine remains in control of step execution.</rule>
-  <rule n="8">LOAD the instructions file specified by 'instructions' key</rule>
-  <rule n="9">READ the ENTIRE instructions file — never use offset/limit</rule>
-  <rule n="10">CHECK quality_gates.pre_start — HALT if any gate fails</rule>
-  <rule n="11">If workflow.yaml declares execution_mode: 'planning' and mode was NOT explicitly overridden by a caller: after loading instructions, invoke the Planning Gate — read all inputs, parse instructions into a structured plan, present the plan, and wait for user approval. User selects runtime mode (normal/yolo) at approval.</rule>
-  <rule n="12">PROCESS each step in the instructions file in strict numerical order</rule>
-  <rule n="13">After each step: WRITE checkpoint to _memory/checkpoints/</rule>
-  <rule n="14">At template-output: SAVE to file, then prompt user (unless YOLO mode)</rule>
-  <rule n="15">CHECK quality_gates.post_complete — HALT if any gate fails</rule>
-  <rule n="16">On completion: archive checkpoint to completed/</rule>
-</WORKFLOW-RULES>
-
-<flow>
-  <step n="1" title="Load and Resolve Config">
-    <action>Read the workflow.yaml file passed as 'workflow-config'</action>
-    <action>Check for pre-resolved config at {module}/.resolved/{name}.yaml</action>
-    <action if="pre-resolved exists">Load pre-resolved config (skip inheritance chain)</action>
-    <action if="no pre-resolved">Load config_source file, resolve field references</action>
-    <action>Resolve {project-root} to actual filesystem project root path</action>
-    <action>Resolve {project-path}: READ the file {project-root}/_gaia/_config/global.yaml and extract the project_path field value. If project_path is "." or the field is missing, set {project-path} = {project-root}. Otherwise, set {project-path} = {project-root}/{project_path}. You MUST actually read the file — do not assume the default. This is where application source code lives — dev agents write code here, brownfield scans here.</action>
-    <action>Resolve {memory_path}: READ the file {project-root}/_gaia/_config/global.yaml and extract the memory_path field value. Resolve any {project-root} references within it. This is where agent memory sidecars live.</action>
-    <action>Resolve {checkpoint_path}: extract the checkpoint_path field from global.yaml. Resolve any {project-root} references within it. This is where workflow checkpoints are stored.</action>
-    <action>Resolve {installed_path} from workflow.yaml location</action>
-    <action>Resolve {date} to current date</action>
-    <action>Ask user for any remaining unresolved variables</action>
-  </step>
-
-  <step n="2" title="Preflight Validation">
-    <action>Invoke preflight-check protocol</action>
-    <action>Verify all file paths in workflow.yaml actually exist</action>
-    <action>Verify instructions file exists and is readable</action>
-    <action>Verify validation/checklist file exists if declared</action>
-    <action>Check quality_gates.pre_start conditions if declared</action>
-    <action if="any gate fails">HALT with clear error message — do NOT proceed</action>
-  </step>
-
-  <step n="3" title="Load Agent Persona">
-    <action>Check if workflow.yaml contains an 'agent' field</action>
-    <action if="agent is 'orchestrator' or field is missing">Skip persona loading — execute as the generic workflow engine</action>
-    <action if="agent field exists and is not 'orchestrator'">Resolve the agent file path: {project-root}/_gaia/{module}/agents/{agent}.md</action>
-    <action if="agent is 'dev-*' (wildcard)">Check if workflow.yaml declares agent_auto_detect: true. If true, execute the agent_auto_detect_strategy from workflow.yaml to determine the stack. If auto-detection succeeds, resolve to {project-root}/_gaia/dev/agents/{detected_stack}-dev.md and inform user: "Auto-detected developer: {agent_name} based on {detection_source}." If auto-detection fails or agent_auto_detect is false/absent: ask user which stack developer to use (typescript, angular, flutter, java, python, mobile, go), then resolve to {project-root}/_gaia/dev/agents/{stack}-dev.md</action>
-    <action if="agent file resolved">Read the agent persona file — adopt its persona, name, communication style, rules, and domain knowledge for the duration of this workflow</action>
-    <action if="agent file resolved">Do NOT execute the agent's activation protocol, greeting, or menu — the workflow engine controls step execution</action>
-    <action if="agent file resolved">Do NOT load the agent's memory sidecar — the workflow engine manages its own checkpoints</action>
-    <action if="agent file resolved">Check for {project-root}/_gaia/_config/agents/{agent-id}.customize.yaml. If found, load and merge overrides (persona_overrides, menu_additions, menu_removals, skill_additions, rule_additions, skill_overrides, skill_section_overrides). For dev agents, also check all-dev.customize.yaml and merge (agent-specific takes precedence over all-dev).</action>
-  </step>
-
-  <step n="4" title="Load Instructions">
-    <action>Read the FULL instructions file (xml or md)</action>
-    <action>Count total steps in the instructions</action>
-    <action>Write initial checkpoint: workflow started, step 0 of N, files_touched: []</action>
-  </step>
-
-  <step n="5" title="Planning Gate" if="execution_mode == 'planning'">
-    <action>Check workflow.yaml for 'execution_mode' field — default to 'normal' if absent</action>
-    <action if="execution_mode != 'planning'">Skip this step — proceed to Process Instructions</action>
-    <action if="mode was explicitly set by caller (subagent prompt) AND mode is NOT yolo">Skip this step — use the caller-requested mode</action>
-    <action if="mode was explicitly set by caller as yolo">Still execute the Planning Gate to generate the plan. After generating, check if workflow.yaml declares val_auto_in_yolo: true and the planning step number (5) is in val_auto_in_yolo_steps. If so, auto-invoke val-validate-artifact to validate the plan. If Val returns CRITICAL/WARNING findings: auto-fix the plan, re-invoke Val, repeat up to 3 iterations. If resolved: auto-approve the plan and set runtime mode to yolo. If unresolved after 3 iterations: HALT with findings list. If Val prerequisites not met or val_auto_in_yolo is false: auto-approve the plan without Val and set runtime mode to yolo. Do NOT present the [a]/[y]/[r]/[x] prompt — the plan is auto-approved after Val passes.</action>
-    <action>Invoke discover-inputs protocol to load all declared input files</action>
-    <action>Parse the loaded instructions to extract: step titles, action summaries, template-output paths, optional steps, skill references, subagent invocations</action>
-    <action>For input files: extract brief context (key metadata, not full content)</action>
-    <action>Present structured execution plan to user using the planning-output format: Context, Files to Modify, Detailed Edits, Version Bumps (if applicable), Implementation Order, Verification. Omit empty sections.</action>
-    <action>Prompt: "[a] Approve (normal) | [y] Approve (YOLO) | [r] Revise plan | [x] Abort"</action>
-    <action if="[a]">Set runtime mode to normal — proceed to Process Instructions</action>
-    <action if="[y]">Set runtime mode to yolo — proceed to Process Instructions</action>
-    <action if="[r]">Ask for feedback, regenerate plan, re-prompt</action>
-    <action if="[x]">HALT — write checkpoint noting user abort</action>
-    <action>Write checkpoint: planning gate approved, selected runtime mode</action>
-  </step>
-
-  <step n="6" title="Process Instructions">
-    <action>Execute each step in strict numerical order</action>
-    <action>For each step: read any required skills/knowledge JIT</action>
-    <action>Before loading a skill file or skill section, check for overrides in this order: (1) active agent's {agent-id}.customize.yaml skill_overrides — if the skill name matches, load the entire file from the override source path. (2) active agent's skill_section_overrides — if skill name + section ID matches, load that section from the override path. (3) For dev agents, repeat checks against all-dev.customize.yaml. (4) Fall back to default path from skill-registry. When loading a skill from an override path, do NOT use _skill-index.yaml line ranges — scan the override file for &lt;!-- SECTION: xxx --&gt; markers dynamically. Relative source paths (without {project-root} prefix) are resolved against custom_skills_path from dev/config.yaml.</action>
-    <action>For each step: drop prior step's skills/knowledge from context</action>
-    <action>Handle supported tags: step, action, ask, check, template-output, goto, invoke-workflow, invoke-task</action>
-    <action>At optional steps: ask user to include/skip (auto-skip in YOLO mode)</action>
-    <action>At ask tag: MANDATORY interaction point — present the question exactly as written and WAIT for user response. Do NOT infer the answer from loaded context. Do NOT skip even if upstream artifacts contain the information. In YOLO mode: auto-answer from context if unambiguous, otherwise ask.</action>
-    <action>At template-output: save output to declared file path</action>
-    <action>After saving template-output: scan the generated content for open question indicators — unchecked checkboxes ("- [ ]"), section headers ("## Open Questions", "## Unresolved", "## Decisions Needed", "## Contradictions", "## Blocking Issues", "## Required Fixes"), and inline markers ("TBD", "TODO", "(needs decision)"). If any found: count the questions, extract their text, and display a guidance block BEFORE the [c]/[y]/[e] prompt:
-
-  --- Open Questions ({N}) ---
-  This artifact contains {N} open question(s) that need your input:
-  {numbered list of each question}
-
-  Recommended: Press [e] to answer these questions now.
-  Why: {next workflow from lifecycle-sequence.yaml} depends on these decisions.
-       Unanswered questions force downstream agents to make assumptions.
-
-  Skip: Press [c] to continue. Questions remain in the artifact.
-  ---
-
-  If no open question indicators are found, skip this guidance and proceed to the standard prompt.</action>
-    <action>At template-output: check if Val integration is enabled. Read {project-root}/_gaia/_config/global.yaml and check if val_integration.template_output_review is true. If true, check if {project-root}/_gaia/lifecycle/agents/validator.md exists AND {project-root}/_memory/validator-sidecar/ exists. If all three conditions pass, extend the template-output prompt to include [v] Review with Val. If any condition fails, show only [c]/[y]/[e] — no [v] option, no error, no message.</action>
-    <action>At template-output in normal mode: first check if workflow.yaml declares a template_output_prompt field. If set to "auto": skip the template-output prompt entirely — save the file and auto-proceed to the next step with no user interaction. This is for read-only outputs (dashboards, reports) that need no user review. If set to a custom string (not "auto"): use that custom prompt string instead of the default options — parse [e] and [v] handlers from it as usual, and for any other user input auto-proceed to the next step. If template_output_prompt is absent: use the default prompt — if Val integration is enabled, show user the output and offer [c] Continue | [y] YOLO | [e] Edit | [v] Review with Val. If Val integration is not enabled, show user the output and offer [c]ontinue [y]olo [e]dit.</action>
-    <action>At [v] handler: when user presses [v], first check if the artifact file path has content. If the artifact has not been written yet or is empty, display "No artifact content to validate yet." and return to the template-output prompt without invoking Val. If content exists, invoke val-validate-artifact as a subagent, passing the artifact_path (the file just saved at template-output) and the source_workflow (the current workflow name from workflow.yaml). If Val completes and returns findings, present findings to the user and let user approve which findings to apply. Only approved findings are written to the artifact under a "## Validation Findings" section. After writing, return to the template-output prompt with the updated artifact content. If Val completes with zero findings, display "Validation complete: no issues found." and return to the template-output prompt with [c]/[y]/[e]/[v] options. If Val's subagent invocation fails for any reason (model unavailable, context too large, timeout), display "Val validation could not complete: {reason}. Continuing without validation." and return to the template-output prompt with [c]/[y]/[e]/[v] options. The user is never left stuck.</action>
-    <action>At template-output in yolo mode: auto-continue UNLESS open question indicators were detected — if detected, pause and display guidance as in normal mode. Open questions require human input and cannot be auto-answered. The [v] option is not auto-triggered in YOLO mode UNLESS the workflow.yaml declares val_auto_in_yolo: true AND the current instruction step number is listed in val_auto_in_yolo_steps AND Val integration prerequisites pass (global.yaml val_integration.template_output_review is true, validator.md exists, validator-sidecar/ exists). When all conditions are met: auto-invoke val-validate-artifact as a subagent with the artifact_path (file just saved) and source_workflow. If Val returns CRITICAL or WARNING findings: the dev agent must auto-fix them, then re-invoke Val to re-validate. Repeat this fix→validate loop up to 3 iterations. If resolved: save findings and fixes to artifact and validator-sidecar memory, then auto-continue. If unresolved after 3 iterations: HALT and inform user with the list of unresolved findings. INFO-level findings are logged to artifact and validator-sidecar memory but do not block. If Val invocation fails (model unavailable, timeout, context too large): HALT and inform user "Val validation could not complete: {reason}. Cannot proceed without validation in YOLO mode." — do NOT auto-continue.</action>
-    <action>When a subagent returns: present summary of results. In normal mode: wait for user [c]ontinue before proceeding. Subagent completion MUST NOT auto-advance the workflow.</action>
-    <action>After each step completes: write checkpoint with step number, key variables, output paths, and files_touched (for each file created/modified during this workflow, run shasum -a 256 {path} and record path, checksum as "sha256:{hex}", last_modified as ISO 8601)</action>
-  </step>
-
-  <step n="7" title="Completion">
-    <action>Check quality_gates.post_complete conditions if declared</action>
-    <action if="any gate fails">HALT — report which gate failed and why</action>
-    <action>Load validation/checklist file if declared</action>
-    <action>Evaluate all checklist items against completed work</action>
-    <action>Archive checkpoint to _memory/checkpoints/completed/</action>
-    <action>Report workflow complete with summary of outputs</action>
-
-    <!-- Session Memory Save Prompt (E9-S8) — Tier 1/2 agents save session decisions at workflow end -->
-    <!-- Phase 1: Tier resolution — determine if save prompt applies -->
-    <action if="workflow.yaml has no 'agent' field or agent is empty">Skip save prompt silently — no agent to save for. Proceed to next-step suggestions.</action>
-    <action if="agent field exists">Read {project-root}/_memory/config.yaml. If the file does not exist, log "Memory config not found — skipping session save prompt." and proceed to next-step suggestions.</action>
-    <action if="config loaded">Look up the resolved agent ID in _memory/config.yaml: check tiers.tier_1.agents and tiers.tier_2.agents lists. If the agent is not in either Tier 1 or Tier 2 (i.e., Tier 3 or unlisted), skip save prompt silently.</action>
-    <!-- Phase 2: Resolve agent-specific config from _memory/config.yaml -->
-    <action if="agent is Tier 1 or Tier 2">Resolve sidecar_path: read agents.{agent-id}.sidecar from _memory/config.yaml, construct absolute path {project-root}/_memory/{sidecar_value}/</action>
-    <action if="agent is Tier 1">Resolve tier_budget from tiers.tier_1.session_budget</action>
-    <action if="agent is Tier 2">Resolve tier_budget from tiers.tier_2.session_budget</action>
-    <!-- Phase 3: Generate session summary -->
-    <action>JIT-load the context-summarization and decision-formatting sections from _gaia/lifecycle/skills/memory-management.md</action>
-    <action if="agent is Tier 1">Generate session summary per context-summarization format (2K token / ~8,000 character ceiling): include decisions made, context updates, and ground truth corrections.</action>
-    <action if="agent is Tier 2">Generate session summary per context-summarization format (2K token / ~8,000 character ceiling): include decisions made and context updates only (no ground truth — Tier 2 agents do not have ground-truth.md).</action>
-    <action if="no decisions made, no context changed, no ground truth corrected">Display "No persistable decisions this session." and offer [y] Save anyway | [n] Skip. If user selects [n], skip to next-step suggestions.</action>
-    <!-- Phase 4: User confirmation — YOLO pauses here (open-question) -->
-    <action>Display the generated session summary to the user.</action>
-    <action>Present save confirmation prompt: "[y] Save | [n] Skip | [e] Edit summary". This is classified as an open-question indicator — YOLO mode MUST pause here and require explicit user confirmation. Memory writes are never auto-approved.
-      - [y]: proceed to session-save skill invocation
-      - [n]: skip the save, proceed to next-step suggestions without writing any memory files and without raising an error
-      - [e]: allow user to edit the summary text, then re-display and re-prompt</action>
-    <!-- Phase 5: Invoke session-save skill (only on [y]) -->
-    <action if="user selected [y]">JIT-load the session-save section from _gaia/lifecycle/skills/memory-management.md. Invoke session-save with parameters: sidecar_path, tier_budget, new_entries (formatted per decision-formatting), context_summary (the generated or edited summary), and third_file_content (ground truth updates for Tier 1, omitted for Tier 2). Budget enforcement runs within the skill — the engine does not implement save logic inline.</action>
-    <!-- End Session Memory Save Prompt -->
-
-    <action>Load _gaia/_config/lifecycle-sequence.yaml and look up current workflow name in sequence</action>
-    <action>If entry has next.primary: present "Suggested next step: {command}" with description from workflow-manifest.csv</action>
-    <action>If entry has next.on_pass/on_fail: present conditional suggestions based on workflow outcome</action>
-    <action>If entry has next.alternatives or next.parallel: list them with their context</action>
-    <action>If entry has next.standalone: say "This is a standalone workflow. Return to your current lifecycle phase."</action>
-    <action>If entry has next.suggestions: list them as optional suggestions with context</action>
-    <action>IMPORTANT: Only suggest commands that exist in workflow-manifest.csv — never invent command names</action>
-  </step>
-</flow>
-
-<execution-modes>
-  <mode name="normal">
-    Pause at every template-output for user confirmation.
-    Prompt: "[c] Continue | [y] Switch to YOLO | [e] Edit output"
-    Pause at every ask tag — present the question and WAIT for user response.
-    NEVER infer or skip an ask, even if the answer appears available from context.
-    Pause when a subagent returns — show results summary and wait for [c]ontinue.
-    DEFAULT: When in doubt about whether to pause, PAUSE.
-  </mode>
-  <mode name="yolo">
-    Auto-proceed past template-outputs without pausing.
-    User can say "switch to normal mode" at any time to return to normal mode.
-  </mode>
-  <mode name="planning">
-    After loading instructions and before processing steps:
-    read all inputs, parse instructions into a structured execution plan,
-    and require user approval before proceeding.
-    Plan format uses structured sections: Context, Files to Modify, Detailed Edits,
-    Version Bumps (if applicable), Implementation Order, Verification. Omit empty sections.
-    User selects runtime mode (normal or yolo) at the approval prompt.
-    If invoked as a subagent with an explicit mode override that is NOT yolo, skip the planning gate.
-    If invoked with yolo mode: still generate the plan, but auto-approve after Val validation passes (if val_auto_in_yolo is enabled). Do not show the approval prompt.
-  </mode>
-</execution-modes>
-
-<supported-tags>
-  <structural>
-    step, action, ask, check, critical, mandate, output
-  </structural>
-  <execution>
-    template-output, goto, anchor, invoke-workflow, invoke-task, invoke-protocol
-  </execution>
-  <conditional>
-    if (attribute on action/check), optional (attribute on step)
-  </conditional>
-  <deferred-v2>
-    for-each, repeat, parallel (unreliable with LLMs — defer to v2.0)
-  </deferred-v2>
-</supported-tags>
-
-<protocols>
-  <protocol name="discover-inputs" file="protocols/discover-inputs.xml" />
-  <protocol name="preflight-check" file="protocols/preflight-check.xml" />
-  <protocol name="handoff" file="protocols/handoff.xml" />
-  <protocol name="review-gate-check" file="protocols/review-gate-check.xml" />
-  <protocol name="status-sync" file="protocols/status-sync.xml" />
-</protocols>
-
-<llm final="true">
-<mandate>NEVER skip steps. NEVER reorder steps. NEVER proceed past a failed quality gate.</mandate>
-<mandate>ALWAYS write checkpoints. ALWAYS load skills JIT. ALWAYS stay under 40K tokens.</mandate>
-<mandate>In normal mode: ALWAYS pause at template-output, ask, and subagent-return boundaries. Proceeding without user input in normal mode is a VIOLATION.</mandate>
-</llm>
-
-</task>

package/_gaia/core/module-help.csv

@@ -1,21 +0,0 @@
-name,code,command,description,agent
-"brainstorming","brainstorming","gaia-brainstorming","Facilitated brainstorming session","orchestrator"
-"party-mode","party-mode","gaia-party","Multi-agent group discussion","orchestrator"
-"help","help","gaia-help","Context-sensitive help and routing","orchestrator"
-"resume","resume","gaia-resume","Resume from last checkpoint","orchestrator"
-"build-configs","build-configs","gaia-build-configs","Regenerate resolved configs","orchestrator"
-"editorial-prose","editorial-prose","gaia-editorial-prose","Clinical copy-editing review","tech-writer"
-"editorial-structure","editorial-structure","gaia-editorial-structure","Structural editing review","tech-writer"
-"adversarial-review","adversarial","gaia-adversarial","Cynical adversarial review","orchestrator"
-"edge-case-hunter","edge-cases","gaia-edge-cases","Edge case analysis","orchestrator"
-"shard-doc","shard-doc","gaia-shard-doc","Split large doc into sections","tech-writer"
-"index-docs","index-docs","gaia-index-docs","Generate doc index for folder","tech-writer"
-"review-security","review-security","gaia-review-security","OWASP-focused security review","security"
-"review-api-design","review-api","gaia-review-api","Review REST API design","orchestrator"
-"review-dependency-audit","review-deps","gaia-review-deps","Audit project dependencies","orchestrator"
-"review-accessibility","review-a11y","gaia-review-a11y","Review for WCAG 2.1 compliance","orchestrator"
-"review-performance","review-perf","gaia-review-perf","Review code for performance issues","orchestrator"
-"merge-docs","merge-docs","gaia-merge-docs","Merge multiple markdown files","tech-writer"
-"generate-changelog","changelog","gaia-changelog","Generate changelog from git history","orchestrator"
-"summarize-doc","summarize","gaia-summarize","Generate executive summary","orchestrator"
-"validate-framework","validate-framework","gaia-validate-framework","Run GAIA framework self-validation","orchestrator"

package/_gaia/core/protocols/agent-specification-protocol.md

@@ -1,103 +0,0 @@
-```xml
-<protocol name="agent-specification-contract" version="1.0">
-
-<purpose>
-Universal contract all GAIA agents share. Agent files reference this protocol
-via protocol-ref attribute but load it JIT — never pre-loaded. Each agent's
-inline specification block holds agent-specific scope, authority, and DoD.
-</purpose>
-
-<conflict-resolution>
-  <rule>User is the final arbiter in all disputes between agents</rule>
-  <rule>Domain expert agent has authority within its declared scope</rule>
-  <rule>When scopes overlap: the agent whose workflow initiated the work leads</rule>
-  <rule>When agents disagree on a decision: present both positions to user with trade-offs</rule>
-  <rule>Never override another agent's output without user consent</rule>
-</conflict-resolution>
-
-<decision-authority-matrix>
-  <purpose>When cross-artifact contradictions are detected, this matrix defines
-  which agent's recommendation takes precedence. User remains final arbiter.
-  Referenced by implementation-readiness workflow contradiction check.</purpose>
-  <domain name="technology-selection" authority="architect" agent="Theo" />
-  <domain name="component-boundaries" authority="architect" agent="Theo" />
-  <domain name="api-contracts" authority="architect" agent="Theo" />
-  <domain name="data-model" authority="architect" agent="Theo" />
-  <domain name="auth-mechanism" authority="security" agent="Zara" />
-  <domain name="threat-severity" authority="security" agent="Zara" />
-  <domain name="security-requirements" authority="security" agent="Zara" />
-  <domain name="encryption-standards" authority="security" agent="Zara" />
-  <domain name="deployment-topology" authority="devops" agent="Soren" />
-  <domain name="container-orchestration" authority="devops" agent="Soren" />
-  <domain name="ci-cd-pipeline" authority="devops" agent="Soren" />
-  <domain name="monitoring-alerting" authority="devops" agent="Soren" />
-  <domain name="feature-scope" authority="pm" agent="Derek" />
-  <domain name="requirement-priority" authority="pm" agent="Derek" />
-  <domain name="nfr-targets" authority="pm" agent="Derek" />
-  <domain name="test-strategy" authority="test-architect" agent="Sable" />
-  <domain name="ux-patterns" authority="ux-designer" agent="Christy" />
-  <overlap-rule>When a contradiction spans two domains (e.g., auth-mechanism
-  vs deployment-topology), the domain with higher security or safety impact
-  takes precedence. Present both positions to user with trade-offs per
-  conflict-resolution rules above.</overlap-rule>
-</decision-authority-matrix>
-
-<memory-access>
-  <rule>READ own sidecar memory (if declared)</rule>
-  <rule>READ shared artifacts from docs/{planning,implementation,test,creative}-artifacts/</rule>
-  <rule>WRITE only to own sidecar memory and declared output locations</rule>
-  <rule>NEVER write to another agent's sidecar memory</rule>
-  <rule>NEVER read another agent's sidecar unless explicitly instructed by user</rule>
-</memory-access>
-
-<memory-hygiene>
-  <purpose>Defines lifecycle states for sidecar entries and rules for the /gaia-memory-hygiene workflow.</purpose>
-  <entry-states>
-    <state name="ACTIVE">Entry is consistent with current reference artifacts.</state>
-    <state name="STALE">Referenced artifact has changed since entry was recorded.</state>
-    <state name="CONTRADICTED">Current artifact explicitly contradicts this entry.</state>
-    <state name="ORPHANED">Referenced component or feature no longer exists in any artifact.</state>
-    <state name="ARCHIVED">Entry was moved to the Archived section by user action.</state>
-  </entry-states>
-  <rules>
-    <rule>The /gaia-memory-hygiene workflow may read all sidecars — this is user-initiated cross-sidecar access per memory-access rule 5.</rule>
-    <rule>No sidecar entry is modified without explicit user confirmation.</rule>
-    <rule>Archived entries are moved to a ## Archived Decisions section at the end of the sidecar file.</rule>
-    <rule>The sidecar file header and append marker comment must always be preserved.</rule>
-  </rules>
-</memory-hygiene>
-
-<escalation-framework>
-  <trigger>Agent encounters a decision outside its declared scope</trigger>
-  <trigger>Blocking dependency on another agent's output that doesn't exist</trigger>
-  <trigger>Quality gate failure after 2 attempts to resolve</trigger>
-  <trigger>User request conflicts with agent's rules or constraints</trigger>
-  <trigger>Ambiguity that cannot be resolved from available artifacts</trigger>
-  <action>State what you cannot decide and WHY</action>
-  <action>Suggest which agent or user action would resolve it</action>
-  <action>NEVER guess or proceed silently past an escalation trigger</action>
-</escalation-framework>
-
-<resume-behavior>
-  <rule>On activation: check _memory/checkpoints/ for active checkpoint matching current workflow</rule>
-  <rule>If checkpoint found and has files_touched: validate checksums (shasum -a 256) before offering resume — flag DELETED or MODIFIED files, offer Proceed / Start fresh / Review</rule>
-  <rule>If checkpoint found without files_touched: skip validation, offer resume normally</rule>
-  <rule>If no checkpoint: start fresh</rule>
-  <rule>Use /gaia-resume for cross-session recovery</rule>
-</resume-behavior>
-
-<fallback-behavior>
-  <rule>When uncertain about next action: ask user rather than guessing</rule>
-  <rule>When input artifact is missing: HALT and report what's missing and how to produce it</rule>
-  <rule>When a workflow step produces unexpected results: pause and report to user</rule>
-  <rule>Never fabricate data, requirements, or decisions — surface gaps honestly</rule>
-</fallback-behavior>
-
-<quality-expectations>
-  <rule>Every output must be traceable to an input requirement or user request</rule>
-  <rule>Artifacts must be saved to declared output locations, never ad-hoc paths</rule>
-  <rule>Quality gates are enforced, not advisory — workflow halts on failure</rule>
-</quality-expectations>
-
-</protocol>
-```

package/_gaia/core/protocols/review-gate-check.xml

@@ -1,29 +0,0 @@
-<protocol name="review-gate-check">
-<description>
-  Shared protocol invoked by each review workflow after updating its Review Gate row.
-  Checks if ALL reviews have passed and transitions story to done if so.
-</description>
-<critical>
-  <mandate>The Review Gate table must have EXACTLY 6 rows: Code Review, QA Tests, Security Review, Test Automation, Test Review, Performance Review. No other rows are valid. If extra rows exist, remove them.</mandate>
-</critical>
-<step n="1" title="Read Review Gate">
-  <action>Read the story file's Review Gate table</action>
-  <action>If Review Gate section is missing: initialize it with EXACTLY 6 rows — Code Review (PENDING), QA Tests (PENDING), Security Review (PENDING), Test Automation (PENDING), Test Review (PENDING), Performance Review (PENDING). Do NOT add any other rows.</action>
-  <action>If Review Gate table has extra rows beyond the 6 valid ones: remove the invalid rows</action>
-  <action>Parse each row: Review name, Status (PENDING | PASSED | FAILED), Report link</action>
-</step>
-<step n="2" title="Evaluate Gate and Transition">
-  <critical>
-    <mandate>You MUST execute the transition even if the gate was already fully passed before this run. The purpose is to ensure story status matches gate state.</mandate>
-    <mandate>Use the status-sync protocol to update story status — this ensures both story file and sprint-status.yaml stay in sync.</mandate>
-  </critical>
-  <action>Check two things: (1) the Review Gate table rows, (2) the current story status</action>
-  <action>If ALL 6 rows show PASSED AND story status is 'review': read the "Definition of Done" section — verify every item is checked (- [x]). If any item is unchecked: log "BLOCKED: DoD incomplete — {unchecked items}". Do NOT transition to done.</action>
-  <action>If ALL 6 rows show PASSED AND all DoD items checked AND story status is 'review':
-    <invoke-protocol ref="status-sync" story_key="{story_key}" new_status="done" source_workflow="review-gate-check" />
-  </action>
-  <action>If ALL 6 rows show PASSED AND the story status is already 'done': log "Story already done. No update needed."</action>
-  <action>If any row is FAILED: log which reviews failed. Do not change story status.</action>
-  <action>If any row is PENDING: log which reviews are still pending. Do not change story status.</action>
-</step>
-</protocol>

package/_gaia/core/protocols/sprint-status-write-safety.xml

@@ -1,35 +0,0 @@
-<protocol name="sprint-status-write-safety">
-<description>
-  Behavioral contract for writing to sprint-status.yaml. This file is written
-  by multiple workflows and must be treated as a shared resource. Story file
-  frontmatter is the source of truth; sprint-status.yaml is a derived view.
-</description>
-<rules>
-  <rule n="1" title="Story File Is Source of Truth">
-    The story file frontmatter Status field is authoritative for story status.
-    sprint-status.yaml is a derived/cached view. When they diverge, the story
-    file wins. The /gaia-sprint-status sync reconciles drift.
-  </rule>
-  <rule n="2" title="Review Workflows Do Not Write sprint-status.yaml">
-    The 6 review workflows (code-review, qa-generate-tests, security-review,
-    test-automation, test-review, performance-review) MUST NOT write to
-    sprint-status.yaml. They update only the story file (Review Gate table
-    and frontmatter status). The sprint-status sync reconciles later.
-  </rule>
-  <rule n="3" title="Re-Read Before Write">
-    Any workflow that writes to sprint-status.yaml MUST re-read the file
-    immediately before writing. Never rely on a cached or earlier read.
-    The re-read must happen in the same step as the write.
-  </rule>
-  <rule n="4" title="Minimal Write">
-    When updating sprint-status.yaml, modify ONLY the story entry you are
-    responsible for. Do not rewrite entries for other stories. Preserve all
-    fields you are not explicitly changing.
-  </rule>
-  <rule n="5" title="Sync Recovers Drift">
-    Running /gaia-sprint-status reconciles sprint-status.yaml with story file
-    frontmatter. If data drifts, the sync corrects it. This is the recovery
-    mechanism for any write anomalies.
-  </rule>
-</rules>
-</protocol>

package/_gaia/core/protocols/status-sync.xml

@@ -1,49 +0,0 @@
-<protocol name="status-sync">
-<purpose>
-Synchronize story status (and optionally sprint_id) between story file (source of truth),
-sprint-status.yaml (derived view), and story-index.yaml (fast lookup index).
-Called by any workflow that changes story status. Ensures all files stay in sync at every transition.
-</purpose>
-
-<input>story_key, new_status, source_workflow, sprint_id (optional — if provided, update sprint_id field in story file; use "null" to clear it when removing a story from a sprint)</input>
-
-<step n="1" title="Update Story File">
-  <action>Read story file at {implementation_artifacts}/{story_key}-*.md</action>
-  <action>Update YAML frontmatter status field to {new_status}</action>
-  <action if="sprint_id parameter is provided">Update YAML frontmatter sprint_id field to {sprint_id}. If sprint_id is "null", set sprint_id to null (clearing the sprint assignment).</action>
-  <action>Scan the story body (below the frontmatter) for a line matching the pattern "**Status:**" (e.g., "> **Status:** backlog"). If found, update the status value on that line to match {new_status}. This prevents frontmatter/body drift.</action>
-  <action>This is the source of truth — always updated first</action>
-</step>
-
-<step n="2" title="Update sprint-status.yaml">
-  <action>Check if {implementation_artifacts}/sprint-status.yaml exists</action>
-  <action if="sprint-status.yaml does not exist">Skip — sprint not yet created. No entry to update.</action>
-  <action if="sprint-status.yaml exists">Re-read sprint-status.yaml immediately before writing (write safety per sprint-status-write-safety.xml)</action>
-  <action if="sprint-status.yaml exists">Check if {story_key} has an entry in sprint-status.yaml</action>
-  <action if="sprint_id is explicitly set to null AND story_key has entry in sprint-status.yaml">Remove the {story_key} entry from sprint-status.yaml — story is no longer in this sprint.</action>
-  <action if="sprint_id is NOT null (or not provided) AND story_key has entry">Update ONLY the status field of the {story_key} entry to {new_status}. Minimal write — do not modify other stories or fields.</action>
-  <action if="story_key has no entry">Skip — story not yet assigned to a sprint. No entry to update.</action>
-  <action>If sprint-status.yaml update fails for any reason: log warning "{source_workflow}: Failed to sync sprint-status.yaml for {story_key} → {new_status}. Run /gaia-sprint-status to reconcile." and continue — this is non-blocking.</action>
-</step>
-
-<step n="3" title="Update story-index.yaml">
-  <action>Read {implementation_artifacts}/story-index.yaml. If the file doesn't exist, create it with header:
-    # Auto-maintained by status-sync protocol. Do not edit manually.
-    last_updated: "{current ISO 8601 timestamp}"
-    stories: {}</action>
-  <action>Check if {story_key} has an entry in the stories map</action>
-  <action if="story_key has entry">Update: status to {new_status}. If sprint_id parameter provided: update sprint_id. Update last_updated timestamp.</action>
-  <action if="story_key has NO entry">Read the story file frontmatter to populate a new entry:
-    {story_key}:
-      title: {from frontmatter title field}
-      epic: {extract epic key from frontmatter epic field, e.g., "E9 — Enhanced Agent Memory" → "E9"}
-      status: {new_status}
-      sprint_id: {from frontmatter or sprint_id parameter}
-      priority: {from frontmatter}
-      risk: {from frontmatter}
-      author: {from frontmatter}
-      file: {story filename, e.g., "E9-S13-consolidate-dual-gaia-and-memory-directories.md"}
-    Update last_updated timestamp.</action>
-  <action>Write back story-index.yaml. Non-blocking — if write fails, log warning and continue. The index is a performance optimization, not a source of truth.</action>
-</step>
-</protocol>

package/_gaia/core/tasks/editorial-review-prose.xml

@@ -1,42 +0,0 @@
-<task id="editorial-review-prose" name="Editorial Review — Prose">
-<objective>Clinical copy-editing that reviews text for communication clarity, consistency, and readability</objective>
-
-<critical>
-  <mandate>Review ONLY — never rewrite the document. Produce a findings report.</mandate>
-  <mandate>Flag issues with specific line references and suggested fixes</mandate>
-  <mandate>Categorize findings by severity: critical, major, minor, style</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Load Document">
-    <action>Ask user for the document path (or use current selection)</action>
-    <action>Read the entire document</action>
-    <action>Note document type: PRD, story, architecture, readme, etc.</action>
-  </step>
-
-  <step n="2" title="Analyze Prose">
-    <action>Check for these categories:
-      - Ambiguity: vague terms, unclear referents, multiple interpretations
-      - Inconsistency: terms used differently in different places
-      - Redundancy: repeated information, verbose phrases
-      - Jargon: unexplained technical terms, acronyms without definition
-      - Passive voice: where active voice would be clearer
-      - Sentence complexity: overly long or nested sentences
-      - Tone shifts: inconsistent voice or formality level
-    </action>
-  </step>
-
-  <step n="3" title="Generate Report">
-    <action>Produce findings report with:
-      - Executive summary (one paragraph)
-      - Findings table: severity, location, issue, suggested fix
-      - Overall readability score: Clear / Mostly Clear / Needs Work / Major Issues
-    </action>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown findings report with table of issues</format>
-  <location>Displayed to user (not saved unless requested)</location>
-</output>
-</task>

package/_gaia/core/tasks/editorial-review-structure.xml

@@ -1,43 +0,0 @@
-<task id="editorial-review-structure" name="Editorial Review — Structure">
-<objective>Structural editor that proposes cuts, reorganization, and simplification while preserving comprehension</objective>
-
-<critical>
-  <mandate>Review ONLY — never rewrite. Produce a structural findings report.</mandate>
-  <mandate>Focus on document organization, not prose quality (use editorial-review-prose for that)</mandate>
-  <mandate>Propose specific reorganization moves, not vague suggestions</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Load Document">
-    <action>Ask user for the document path</action>
-    <action>Read the entire document</action>
-    <action>Map the current structure: headings, sections, subsections</action>
-  </step>
-
-  <step n="2" title="Analyze Structure">
-    <action>Evaluate these dimensions:
-      - Information architecture: is the hierarchy logical?
-      - Section ordering: does the sequence support understanding?
-      - Section balance: are some sections disproportionately long/short?
-      - Redundancy: are topics covered in multiple places?
-      - Missing sections: are expected sections absent for this doc type?
-      - Depth: are there too many nesting levels (max 3 recommended)?
-      - Navigation: could a reader find information quickly?
-    </action>
-  </step>
-
-  <step n="3" title="Generate Report">
-    <action>Produce structural findings with:
-      - Current structure outline (with line counts per section)
-      - Proposed restructure outline (showing moves, merges, splits)
-      - Specific recommendations: cut, merge, split, reorder, add
-      - Priority: which changes would have the most impact
-    </action>
-  </step>
-</flow>
-
-<output>
-  <format>Markdown report with current vs proposed structure comparison</format>
-  <location>Displayed to user (not saved unless requested)</location>
-</output>
-</task>

package/_gaia/core/tasks/generate-changelog.xml

@@ -1,35 +0,0 @@
-<task id="generate-changelog" name="Generate Changelog">
-<objective>Generate changelog from git history and/or sprint status files</objective>
-
-<critical>
-  <mandate>Follow Keep a Changelog format</mandate>
-  <mandate>Group by: features, bug fixes, improvements, breaking changes</mandate>
-  <mandate>Include version number and date</mandate>
-</critical>
-
-<flow>
-  <step n="1" title="Gather Sources">
-    <action>Check git log for commits since last release tag</action>
-    <action>Read sprint status files if available in {implementation_artifacts}/</action>
-    <action>Identify version number for this changelog entry</action>
-  </step>
-  <step n="2" title="Categorize Changes">
-    <action>Group changes into: Added, Changed, Fixed, Deprecated, Removed, Security</action>
-    <action>Extract meaningful descriptions from commits and story titles</action>
-    <action>Identify breaking changes and migration notes</action>
-  </step>
-  <step n="3" title="Format">
-    <action>Format following Keep a Changelog specification</action>
-    <action>Include date and version header</action>
-    <action>Add links to relevant PRs or issues if available</action>
-  </step>
-  <step n="4" title="Output">
-    <action>Write or append to CHANGELOG.md</action>
-  </step>
-</flow>
-
-<output>
-  <format>Keep a Changelog format markdown</format>
-  <location>CHANGELOG.md in project root</location>
-</output>
-</task>