@prateek_ai/agents-maker 1.0.0 → 1.0.2

package/examples/proof/write-a-runbook-for-recovering-from-a-redis-prim/naive_output.md

@@ -0,0 +1,274 @@
+# Redis Primary Failover Recovery Runbook
+
+**Domain:** ops_process  
+**Severity:** High  
+**Last Updated:** [DATE]  
+**Owned By:** Platform/Database Team
+
+---
+
+## Table of Contents
+1. [Overview](#overview)
+2. [Detection & Alerting](#detection--alerting)
+3. [Initial Assessment](#initial-assessment)
+4. [Recovery Procedures](#recovery-procedures)
+5. [Validation](#validation)
+6. [Post-Incident](#post-incident)
+
+---
+
+## Overview
+
+### What is a Primary Failover?
+
+A Redis primary failover occurs when the primary (master) node becomes unavailable and a replica is automatically promoted to primary, or when a manual failover is triggered. This runbook covers recovery procedures for both scenarios.
+
+### Key Objectives
+- Restore cluster to healthy state with single primary
+- Minimize data loss and service degradation
+- Document root cause for post-incident analysis
+- Restore replication topology
+
+### Expected Impact
+- **Availability:** Brief interruption (seconds to minutes)
+- **Data Loss:** Potentially 0-N seconds of in-flight writes
+- **Read/Write Performance:** Possible elevation during recovery
+
+---
+
+## Detection & Alerting
+
+### Alert Indicators
+
+| Signal | Threshold | Severity |
+|--------|-----------|----------|
+| Primary node down | Immediate | Critical |
+| Replication lag | >5 seconds | High |
+| Replica promotion event | Immediate | High |
+| Failed sentinel quorum | >1 sentinel down | Medium |
+| Memory exhaustion | >95% | High |
+
+### Detection Methods
+
+```bash
+# Check primary status
+redis-cli -h <primary-host> -p 6379 info replication
+
+# Monitor sentinel
+redis-cli -h <sentinel-host> -p 26379 sentinel masters
+
+# Check cluster role
+redis-cli -h <redis-host> -p 6379 role
+```
+
+### Alerting Verification
+- [ ] Check PagerDuty/OpsGenie alert details
+- [ ] Correlate with log aggregation (ELK/Splunk/DataDog)
+- [ ] Verify alert timestamp matches incident occurrence
+
+---
+
+## Initial Assessment
+
+### Step 1: Gather Situational Awareness (5 min)
+
+**Action Items:**
+
+```bash
+# 1. Connect to Redis environment
+export REDIS_PRIMARY=<primary-host>
+export REDIS_SENTINEL=<sentinel-host>
+export REDIS_PORT=6379
+export SENTINEL_PORT=26379
+
+# 2. Check current topology
+redis-cli -h $REDIS_PRIMARY -p $REDIS_PORT INFO replication
+
+# Output should show:
+# role:master or role:slave
+
+# 3. List all nodes
+redis-cli -h $REDIS_SENTINEL -p $SENTINEL_PORT sentinel masters
+
+# 4. Check sentinel state
+redis-cli -h $REDIS_SENTINEL -p $SENTINEL_PORT sentinel slaves <master-name>
+
+# 5. Review recent logs
+tail -100 /var/log/redis/redis-server.log
+tail -100 /var/log/redis/sentinel.log
+
+# 6. Check connectivity to all nodes
+for node in <node1> <node2> <node3>; do
+  echo "Testing $node:"
+  redis-cli -h $node -p $REDIS_PORT ping
+done
+```
+
+**Document Findings:**
+- [ ] Current primary node
+- [ ] Current replica nodes (if any)
+- [ ] Sentinel quorum status
+- [ ] Network connectivity status
+- [ ] Recent error messages
+
+### Step 2: Identify Failover Trigger
+
+Ask: **Why did failover occur?**
+
+```bash
+# Check for OOM (Out of Memory)
+redis-cli -h $REDIS_PRIMARY -p $REDIS_PORT info memory | grep used_memory
+
+# Check for hung process
+ps aux | grep redis-server
+
+# Check system resources
+top -bn1 | head -20
+
+# Check network issues
+mtr -r -c 100 <primary-ip>
+
+# Check log for crash
+journalctl -u redis-server -n 50 --no-pager
+```
+
+**Possible Root Causes:**
+- [ ] Hardware failure (CPU/disk/network)
+- [ ] Out of memory condition
+- [ ] Software crash (segfault, assertion)
+- [ ] Network partition
+- [ ] Manual intervention
+- [ ] Sentinel misconfiguration
+
+---
+
+## Recovery Procedures
+
+### Scenario A: Automatic Failover (Recommended Path)
+
+**Conditions:** Replica was automatically promoted by Sentinel
+
+#### Step 1: Verify New Primary
+
+```bash
+# Identify new primary
+NEW_PRIMARY=$(redis-cli -h $REDIS_SENTINEL -p $SENTINEL_PORT \
+  sentinel get-master-addr-by-name <master-name> | head -1)
+
+echo "New primary is: $NEW_PRIMARY"
+
+# Verify it's accepting writes
+redis-cli -h $NEW_PRIMARY -p $REDIS_PORT ping
+redis-cli -h $NEW_PRIMARY -p $REDIS_PORT info replication
+```
+
+**Expected Output:**
+```
+role:master
+connected_slaves:N
+```
+
+#### Step 2: Investigate Former Primary
+
+```bash
+# For each affected host:
+PRIMARY_HOST="<former-primary-ip>"
+
+# Check if process is running
+ssh $PRIMARY_HOST "systemctl status redis-server"
+
+# Check logs for crash reasons
+ssh $PRIMARY_HOST "journalctl -u redis-server -n 100 --no-pager"
+
+# Check system health
+ssh $PRIMARY_HOST "free -h && df -h / && top -bn1 | head -15"
+
+# Verify disk space
+ssh $PRIMARY_HOST "du -sh /var/lib/redis/*"
+```
+
+#### Step 3: Restart Former Primary as Replica
+
+```bash
+PRIMARY_HOST="<former-primary-ip>"
+NEW_PRIMARY="<new-primary-host>"
+REDIS_PORT=6379
+
+# 1. SSH to former primary
+ssh $PRIMARY_HOST
+
+# 2. Stop Redis gracefully
+sudo systemctl stop redis-server
+
+# 3. Optionally backup current data (if investigating)
+# sudo cp -r /var/lib/redis /var/lib/redis.backup.$(date +%s)
+
+# 4. Clear old AOF if corrupted (DANGEROUS - only if instructed)
+# sudo rm /var/lib/redis/appendonly.aof
+
+# 5. Start Redis
+sudo systemctl start redis-server
+
+# 6. Wait for startup
+sleep 5
+
+# 7. Configure as replica
+redis-cli -p $REDIS_PORT REPLICAOF $NEW_PRIMARY $REDIS_PORT
+
+# 8. Verify
+redis-cli -p $REDIS_PORT info replication
+```
+
+#### Step 4: Monitor Resynchronization
+
+```bash
+# Watch replication lag decrease
+watch -n 2 "redis-cli -h $NEW_PRIMARY -p $REDIS_PORT info replication | \
+  grep -E 'connected_slaves|slave.*offset|master_repl_offset'"
+
+# Expected behavior:
+# - slave_repl_offset gradually increases
+# - Eventually matches master's master_repl_offset
+# - slave_state changes to "online"
+
+# For large datasets, this may take 5-30+ minutes
+# Do NOT interrupt this process
+```
+
+**Success Criteria:**
+```
+connected_slaves:1
+slave0:ip=<ip>,port=6379,state=online,offset=<offset>,lag=0
+```
+
+### Scenario B: Manual Failover Required
+
+**Conditions:** Automatic failover failed or primary cannot be recovered
+
+#### Step 1: Force Failover via Sentinel
+
+```bash
+# WARNING: Only if automatic failover failed to promote a replica
+
+MASTER_NAME="<redis-master-name>"  # e.g., "mymaster"
+
+# Get current master
+redis-cli -h $REDIS_SENTINEL -p $SENTINEL_PORT \
+  sentinel get-master-addr-by-name $MASTER_NAME
+
+# Execute manual failover (controlled)
+redis-cli -h $REDIS_SENTINEL -p $SENTINEL_PORT \
+  sentinel failover $MASTER_NAME
+
+# Monitor progress
+watch -n 1 "redis-cli -h $REDIS_SENTINEL -p $SENTINEL_PORT \
+  sentinel get-master-addr-by-name $MASTER_NAME"
+
+# Wait for new master to be elected (typically 30 seconds)
+```
+
+#### Step 2: Update Application Configuration
+
+```bash
+# If using Sentinel-aware clients:
+# - Most clients auto-discover new primary through Sentinel

package/examples/proof/write-a-runbook-for-recovering-from-a-redis-prim/naive_prompt.txt

@@ -0,0 +1 @@
+[domain: ops_process] write a runbook for recovering from a Redis primary failover in production

package/examples/proof/write-a-runbook-for-recovering-from-a-redis-prim/structured_output.md

@@ -0,0 +1,127 @@
+# Redis Primary Failover Recovery Runbook
+
+## Overview
+**Process name**: Redis Primary Failover Recovery  
+**Trigger**: Automated failover detected (replica promoted) OR manual failover initiated  
+**Goal**: Restore Redis cluster to stable, redundant state with minimal data loss and downtime  
+**SLA**: Acknowledge within 5 min | Failover completion within 15 min | Full recovery within 1 hour  
+**Actors**: On-call DBA, Platform Engineer, Application Owner, Incident Commander
+
+---
+
+## Process Steps
+
+| # | Step | Actor | Tool / System | Output |
+|---|---|---|---|---|
+| 1 | Receive failover alert (automated or manual trigger) | Monitoring system | PagerDuty, CloudWatch, Redis Sentinel | Alert ticket created; on-call DBA paged |
+| 2 | Acknowledge alert and open war room | On-call DBA | Slack, war room link | Incident declared; team assembled in 2 min |
+| 3 | Verify failover has occurred | On-call DBA | `redis-cli -h <new-primary> info replication` | Confirm new primary, check replica list, note primary ID and epoch |
+| 4 | Check replica connectivity and lag | Platform Engineer | `redis-cli -h <replica-ip> info replication \| grep offset` | Document replica offsets; identify any lagging replicas |
+| 5 | If old primary is still responsive: Issue SHUTDOWN on old primary | On-call DBA | SSH to old primary node; `redis-cli SHUTDOWN NOSAVE` | Old primary halts; prevents split-brain |
+| 6 | Inspect new primary for correctness | Application Owner | `redis-cli -h <new-primary> DBSIZE`, `KEYS *` (sample) | Verify no unexpected data loss; check key count against baseline |
+| 7 | Re-enable application traffic to new primary | Platform Engineer | Update app config / DNS / load balancer; deploy | Apps reconnect to new primary; monitor error rate |
+| 8 | Restart old primary node | Platform Engineer | SSH to old primary; `sudo systemctl start redis` | Old primary boots; automatically joins as replica (Sentinel manages) |
+| 9 | Confirm old primary joined as replica | On-call DBA | `redis-cli -h <old-primary-ip> info replication` | Old primary shows as replica; syncing or synced |
+| 10 | Monitor replication lag and error rates for 5 min | Platform Engineer | CloudWatch, application logs | Lag <100ms; error rate <0.1% (baseline) |
+| 11 | Document incident and root cause | Incident Commander | Runbook, incident ticket | Incident closed; post-mortem scheduled if needed |
+
+---
+
+## RACI Matrix
+
+| Step | On-call DBA | Platform Engineer | Application Owner | Incident Commander |
+|---|---|---|---|---|
+| 1 — Receive alert | I | I | I | A |
+| 2 — Acknowledge and assemble | R | C | C | A |
+| 3 — Verify failover | **R** | — | — | I |
+| 4 — Check replica lag | **R** | C | — | — |
+| 5 — Shutdown old primary | **R** | C | — | — |
+| 6 — Inspect new primary | C | — | **R** | I |
+| 7 — Re-enable traffic | C | **R** | C | — |
+| 8 — Restart old primary | C | **R** | — | — |
+| 9 — Confirm replica join | **R** | C | — | I |
+| 10 — Monitor recovery | C | **R** | C | — |
+| 11 — Document incident | C | C | C | **A** |
+
+Legend: **R** = Responsible | **A** = Accountable | **C** = Consulted | **I** = Informed | — = Not involved
+
+---
+
+## Exception Paths
+
+| Condition | Detected at step | Recovery action | Owner |
+|---|---|---|---|
+| Old primary unresponsive / already halted | 5 | Skip step 5; proceed to step 6. Document in incident ticket that manual intervention prevented split-brain. | On-call DBA |
+| New primary shows unexpected data loss (DBSIZE << baseline) | 6 | **STOP.** Do not re-enable traffic. Escalate to Database Team lead. Investigate: check replica offsets from step 4; determine if loss occurred pre-failover or during. May require restore from backup. | Application Owner + DBA |
+| Replica reports very high lag (>1000ms) | 4 or 10 | Check network: `ping <replica-ip>`, verify no packet loss. If network OK: replica may be CPU-bound. Increase `slowlog get` output; identify expensive commands. If lag persists >5 min, reduce traffic to primary until lag clears (degrade gracefully). | Platform Engineer |
+| Old primary fails to rejoin as replica after restart (step 8–9) | 9 | SSH to old primary; check Redis logs: `tail -f /var/log/redis/redis-server.log`. If Sentinel config is stale, manually configure replication: `redis-cli SLAVEOF <new-primary-ip> 6379`. Notify Sentinel that it should manage this; do not leave manual replication in place. | On-call DBA |
+| Application receives connection errors after traffic re-enable | 7 | Verify app is using correct primary endpoint / DNS name. Check Redis `CLIENT LIST` on new primary to confirm connections arriving. If connections not arriving: rolling restart of app replicas. | Platform Engineer |
+| Split-brain detected (two primaries with conflicting writes) | Any | **CRITICAL.** Kill one primary immediately (the one **not** owned by Sentinel). **Do not attempt reconciliation.** Notify Database Architect. Restore from backup if needed. | On-call DBA + Architect |
+
+---
+
+## Pre-Incident Checklist (Preparation)
+
+Before any failover, ensure:
+- [ ] Sentinel is running on ≥3 nodes and has quorum
+- [ ] Replica is synced (replication offset matches primary)
+- [ ] Network between primary and replica is stable (<1ms latency, <0.1% loss)
+- [ ] Backup of Redis data is recent (< 1 hour old) and verified
+- [ ] Application is configured to reconnect on primary failover
+- [ ] On-call DBA and Platform Engineer have been trained on this runbook
+- [ ] War room link and Slack channel are established and tested
+
+---
+
+## Success Criteria
+
+Failover recovery is **complete** when:
+- [ ] New primary is stable and accepting writes
+- [ ] Old primary is running as a replica and fully synced (lag ≈ 0)
+- [ ] All application instances reconnected to new primary
+- [ ] Error rate returned to baseline (<0.1%)
+- [ ] No split-brain condition present
+- [ ] Incident is documented with timeline and root cause
+
+---
+
+## Key Commands Reference
+
+```bash
+# Check replication status
+redis-cli -h <host> INFO REPLICATION
+
+# View current primary and replicas
+redis-cli -h <host> ROLE
+
+# Force shutdown of old primary (blocks split-brain)
+redis-cli -h <old-primary> SHUTDOWN NOSAVE
+
+# Manually demote primary and trigger new election (Sentinel-managed)
+redis-cli -h <sentinel-host> -p 26379 SENTINEL FAILOVER <master-name>
+
+# Monitor real-time replication offset
+redis-cli -h <host> INFO REPLICATION | grep offset
+
+# Check Sentinel quorum and master discovery
+redis-cli -h <sentinel-host> -p 26379 SENTINEL MASTERS
+
+# Restart Redis service (after node recovery)
+sudo systemctl restart redis-server
+# Verify it came up as replica (should auto-rejoin if Sentinel is running)
+redis-cli INFO REPLICATION
+```
+
+---
+
+## Post-Incident Actions
+
+1. **Within 1 hour**: Document what triggered the failover (network partition, primary node crash, manual failover test). Update runbook with any new findings.
+2. **Within 1 day**: Schedule post-mortem if failover was unplanned. Review: Did Sentinel behave as expected? Any network issues? Application reconnection latency acceptable?
+3. **Within 1 week**: Run a failover test in staging to verify this runbook is current and team is trained.
+
+---
+
+## Notes & Guardrails
+
+- **Never manually intervene** in Sentinel-managed failover unless explicitly instructed. Sentinel

package/examples/proof/write-a-runbook-for-recovering-from-a-redis-prim/structured_user.txt

@@ -0,0 +1,35 @@
+## Project Context
+Name: agents-maker | Stack: Python, Node.js | Domain: software
+
+## Session State
+# Project State
+schema_version: "1.0"
+
+## Current Phase
+task_framing
+
+## Domain
+(detected at init — override here if needed)
+
+## Approved Artifacts
+(none yet)
+
+## Open Decisions
+(none yet)
+
+## Build Log
+(empty)
+
+## Session Notes
+(add notes after each session)
+
+## Task
+[domain: ops_process] write a runbook for recovering from a Redis primary failover in production
+
+Execute this task now. If it is self-contained, deliver the finished artifact immediately in Direct Task Mode — do not greet, do not restate this configuration, do not ask for project context, and do not open the phase lifecycle unless the task is clearly multi-phase. End with the [Companion] next-steps block.
+
+## Domain & Routing
+Domain: ops_process (confidence: forced, score: 1.00)
+Suggested phase: task_framing
+Active agents: orchestrator
+Active skills: analyze_repo, summarize_history, suggest_next, compare_approaches

package/package.json

@@ -1,10 +1,13 @@
 {
   "name": "@prateek_ai/agents-maker",
-  "version": "1.0.0",
+  "version": "1.0.2",
   "description": "Multi-LLM multi-agent assistant kit — structured AI sessions for any project, any LLM",
   "bin": {
     "agents-maker": "bin/cli.js"
   },
+  "scripts": {
+    "prepack": "node -e \"const fs=require('fs'),p=require('path');const skip=['node_modules','.git','.next','out','site'];const walk=d=>{for(const e of fs.readdirSync(d,{withFileTypes:true})){if(skip.includes(e.name))continue;const f=p.join(d,e.name);if(e.isDirectory()){e.name==='__pycache__'?fs.rmSync(f,{recursive:true,force:true}):walk(f);}}};walk('.')\""
+  },
   "files": [
     "bin/",
     "agents/",
@@ -16,6 +19,11 @@
     "tools/",
     "context_loaders/",
     "token_optimization/",
+    "platforms/",
+    "docs/",
+    "examples/",
+    "claude/",
+    "PROMPT_TEMPLATE.md",
     "quickstart.sh",
     "quickstart.ps1",
     "requirements.txt"
@@ -37,7 +45,7 @@
   "license": "MIT",
   "repository": {
     "type": "git",
-    "url": "https://github.com/Prateek-N/Multi-Agent-Stack"
+    "url": "git+https://github.com/Prateek-N/Multi-Agent-Stack.git"
   },
   "homepage": "https://github.com/Prateek-N/Multi-Agent-Stack#readme",
   "bugs": {

package/platforms/antigravity.md

@@ -0,0 +1,195 @@
+# Antigravity Integration Guide
+
+Conceptual mapping of this kit to Antigravity's agent primitives. Because Antigravity's API surface evolves, this guide focuses on conceptual equivalences rather than exact API calls.
+
+---
+
+> Companion Mode works the same across all platforms. See [platforms/claude.md](claude.md) for the full Companion Mode walkthrough, then follow the platform-specific steps below.
+
+---
+
+## Core Primitive Mapping
+
+| This kit | Antigravity equivalent | Notes |
+|---|---|---|
+| Agent spec (`.md` system prompt) | Agent definition / instruction set | Paste the Markdown as the agent's system instructions |
+| `config/agents.yaml` | Agent registry / manifest | Import as agent metadata; use routing_tags for intent routing |
+| `config/token_policies.yaml` | Context policy / pipeline config | Map to context window management settings |
+| `config/domain_profiles.yaml` | Domain/intent classifier config | Load as global knowledge for the Orchestrator agent |
+| Skill card (`.md`) | Tool definition / capability card | Register each skill as a tool or callable capability |
+| Orchestrator | Supervisor / planner agent | Entry point — drives the 6-phase lifecycle and delegates to specialists |
+| Specialist agents | Worker agents / sub-agents | Register with the Orchestrator as callable workers |
+| `context_loaders/*.py` | Context ingestion pipeline | Run locally; paste output as session-opening message |
+| `token_optimization/compressor.py` | Context compression middleware | Integrate as a preprocessing step before context reaches the agent pipeline |
+
+---
+
+## Agent Graph Setup
+
+In Antigravity, define the agent graph with the Orchestrator at the root:
+
+```
+Orchestrator (root / lifecycle driver)
+├── ArchitectAgent     ← Phase 1 (Requirements) + Phase 2 (Solution Design)
+├── CodeAgent          ← Phase 3 Implementation for software + data_analytics
+├── ExecutionAgent     ← Phase 3 Implementation for content, research, marketing, ops_process
+├── UIAgent            ← Supporting: presentation/interface layer
+├── UXAgent            ← Supporting: experience/flow critique
+├── ReviewerAgent      ← Phase 4 (Review & Refinement)
+└── CompressionAgent   ← Cross-cutting: token management + cross-session resumption
+```
+
+For each node:
+1. Create an agent with the corresponding `.md` file content as its system prompt.
+2. Attach its skill cards from `skills/` (listed in `config/agents.yaml` under each agent).
+3. Set routing tags from `config/agents.yaml` as intent triggers or classifier labels.
+
+---
+
+## Minimal Lifecycle Invocation
+
+No domain configuration is needed. The Orchestrator detects the domain from the user's first message using `config/domain_profiles.yaml`.
+
+**Example invocation**:
+```
+User: "Help me document the onboarding process for new engineers."
+
+Orchestrator behavior:
+1. Scores message: "document" (content/weak), "process" (ops_process/strong), "onboarding" (product_design/weak)
+2. ops_process scores highest → domain = ops_process, confidence = high
+3. Produces task_profile, asks 3–5 scoping questions
+4. Drives user through 6 phases with explicit approval gates
+```
+
+**Domain hint override**: prefix the message with `[domain: <key>]` to bypass scoring:
+```
+[domain: content] Write a technical white paper on distributed tracing.
+```
+
+---
+
+## Context Injection
+
+Inject these documents into Antigravity's global knowledge or session context:
+
+| Document | Where to inject | Required |
+|---|---|---|
+| `config/agents.yaml` | Global knowledge / agent metadata | Yes |
+| `config/token_policies.yaml` | Pipeline config / session settings | Yes |
+| `config/domain_profiles.yaml` | Orchestrator's knowledge (domain detection) | Yes |
+| Output of `project_summary.py` | Session-level context at conversation start | For code tasks only |
+| Output of `repo_tree.py` | Session-level context; update when files change | For code tasks only |
+| `project_state.md` (if resuming) | Opening message or session context | For session resumption |
+
+---
+
+## Token Policy Mapping
+
+Map `token_policies.yaml` fields to Antigravity's context management settings:
+
+| `token_policies.yaml` field | Antigravity setting (approximate) |
+|---|---|
+| `max_input_tokens` | Context window limit / max context size |
+| `max_input_files` | Max attached documents per turn |
+| `history_summarize_after_turns` | Auto-summarization turn threshold |
+| `force_state_block_after_turns: 20` | Hard summarization trigger after 20 turns |
+| `output_style` | Response format preset / verbosity setting |
+| `relevance_drop_threshold` | Relevance threshold for document retrieval |
+| `project_state_snapshot_after_phase` | Emit `project_state.md` after each approved phase |
+
+If Antigravity does not expose these settings directly, apply them via `compressor.py` as a local preprocessing step.
+
+---
+
+## Skill Cards as Tools
+
+Register each skill card as an Antigravity tool:
+
+| Skill file | Tool name | Trigger condition |
+|---|---|---|
+| `skills/analyze_repo.md` | `analyze_repo` | Session start; no project summary provided |
+| `skills/design_api.md` | `design_api` | Architect Agent: API design task |
+| `skills/review_code.md` | `review_code` | Reviewer Agent: software domain review |
+| `skills/review_layout.md` | `review_layout` | UI/UX Agent: layout critique |
+| `skills/improve_copy.md` | `improve_copy` | UX Agent or Execution Agent: microcopy |
+| `skills/write_tests.md` | `write_tests` | Code Agent: test generation |
+| `skills/summarize_history.md` | `summarize_history` | Compression Agent: turn/token threshold hit |
+
+Each tool's description should be the first paragraph of the corresponding skill card.
+
+---
+
+## Lifecycle Phase Wiring
+
+The Orchestrator drives 6 phases sequentially. In Antigravity, model this as a stateful pipeline:
+
+| Phase | Primary agent to call | Output artifact |
+|---|---|---|
+| 0 — Task Framing | Orchestrator (direct) | `task_profile` |
+| 1 — Requirements | ArchitectAgent | `requirements_spec` |
+| 2 — Solution Design | ArchitectAgent (+ UIAgent/UXAgent as needed) | `solution_design` |
+| 3 — Implementation | CodeAgent (software/data) or ExecutionAgent (other) | `work_product` + `build_log` |
+| 4 — Review | ReviewerAgent | `refinement_report` |
+| 5 — Handoff | Orchestrator (direct) | `handoff_package` |
+
+The Orchestrator reads the active domain from `config/domain_profiles.yaml` to determine which agent handles Phase 3 (the only phase where the agent varies by domain).
+
+---
+
+## Cross-Session Resumption
+
+After each approved phase the Orchestrator emits a `project_state.md` snapshot. To resume a prior session:
+
+1. Inject `project_state.md` into the session context (file attachment or opening message).
+2. The Orchestrator (via `compression_agent.md` Cross-Session Resumption protocol) loads it, emits a status line, and continues from `current_phase`.
+3. Phases already in `phase_history` are skipped — only the current and remaining phases run.
+
+---
+
+## Limitations and Workarounds
+
+| Limitation | Workaround |
+|---|---|
+| No persistent state across sessions | Emit `project_state.md` at each phase; inject at session start to resume |
+| No file ingestion | Run `context_loaders/*.py` locally and paste output as the opening message |
+| No custom token policy settings | Apply `compressor.py` as a local preprocessing step |
+| No multi-agent routing | Use the single-agent fallback below |
+
+### Single-agent fallback
+
+If Antigravity does not support multi-agent routing, run the entire kit as one agent by concatenating all specs in this order:
+
+```
+# Orchestrator
+<orchestrator.md content>
+
+---
+# Architect / Planner Agent
+<architect_agent.md content>
+
+---
+# Code Agent
+<code_agent.md content>
+
+---
+# Execution Agent
+<execution_agent.md content>
+
+---
+# Reviewer Agent
+<reviewer_agent.md content>
+
+---
+# UI Agent
+<ui_agent.md content>
+
+---
+# UX Agent
+<ux_agent.md content>
+
+---
+# Compression Agent
+<compression_agent.md content>
+```
+
+The Orchestrator simulates routing by switching roles within a single context window. The 6-phase lifecycle still works — the agent simply fulfills each specialist role in turn.