test-repo/MEMORY.md

---

📋 Research Workflow - URL → Document + Task + Plan

When I say: "Research this URL"

Alice-Researcher MUST deliver:

1. ✅ Document in Mission Control Documents
2. ✅ Task in Gantt Board (current sprint for today's date)
3. ✅ Analysis in task description (fit against current infrastructure)
4. ✅ IMPLEMENTATION PLAN ATTACHED if verdict is ADOPT or EVALUATE_LATER

Skill file: /Users/mattbruce/.agents/skills/url-research-to-documents-and-tasks/SKILL.md

Critical checks:

• Sprint must contain today's date (auto-detected)
• Verdict options: ADOPT / EVALUATE_LATER / PASS
• Only PASS skips the implementation plan
• Plan must include: Overview, Current vs Proposed, Phases, Risks, Timeline

Verification before completion:

- [ ] Document exists in Mission Control
- [ ] Task in correct sprint
- [ ] Analysis in description
- [ ] Implementation plan attached (if ADOPT/EVALUATE_LATER)

---

🤖 Agent Workflow - Checklist-Based Task Execution

All agents (Alice/Bob/Charlie) MUST use this checklist format for task updates:

Comment Format (MANDATORY):

## [YYYY-MM-DD HH:MM] 🔄 [STATUS] - [Agent Name]

### ✅ Completed
- [x] Task 1: Description - **DONE** - Details
- [x] Task 2: Description - **DONE** - Details
- [ ] Task 3: Description - **IN PROGRESS** - Current status

### 🔄 In Progress
- [ ] Task 4: Description - Started at HH:MM, expected completion HH:MM

### 📋 Remaining
- [ ] Task 5: Description - Prerequisites: X, Y
- [ ] Task 6: Description - Blocked by: Z
- [ ] Task 7: Description - Estimated effort: X hours

### 🎯 Next Steps
1. [Immediate next action]
2. [Follow-up action]
3. [Final validation]

### 🚨 Blockers (if any)
- [Issue]: [Description] - [Solution attempt]

### 📊 Progress: X/Y tasks complete (Z%)

Resumability Rules:

• Every session starts by reading ALL previous comments chronologically
• Resume from last incomplete task in checklist
• Never repeat completed work - check ✅ Completed section
• Update progress before ending session

Agent-Specific Checklists:

Alice-Researcher:

• ✅ Extract content from URL (Tavily → Scrapling fallback)
• ✅ Create Mission Control document
• ✅ Create Gantt Board task in current sprint
• ✅ Analyze fit vs current infrastructure
• ✅ Attach implementation plan (if ADOPT/EVALUATE_LATER)

Bob-Implementer:

• ✅ Understand requirements from task description/comments
• ✅ Plan implementation approach
• ✅ Write/modify code with tests
• ✅ Run tests and validate locally
• ✅ Commit changes with clear message
• ✅ Update documentation if needed

Charlie-Tester:

• ✅ Review code changes and understand requirements
• ✅ Run automated tests
• ✅ Manual testing of all functionality
• ✅ Check edge cases and error handling
• ✅ Update task to done when approved

Status Flow:

• open → in-progress (starting work)
• in-progress → review (implementation complete, needs validation)
• review → done (approved/validated)

CLI Commands for Updates:

# Update status
./task.sh update [task_id] --status in-progress

# Add detailed progress comment
./task.sh update [task_id] --comment "[full checklist markdown]"

This ensures perfect resumability — if an agent fails, the next session continues exactly where it left off.

---

🔧 Configuration Management

TOOLS.md = Single Source of Truth

ALL configuration variables and endpoints must be documented in TOOLS.md:

• Service URLs (production + dev)
• API keys and credentials
• Database connection strings
• Authentication tokens
• File paths and directories
• Environment-specific settings

If information is missing from TOOLS.md:

• Stop and ask user to add it
• Do NOT guess or use defaults
• Document what was needed for future reference

Self-Healing Pattern: When operations fail:

1. Check TOOLS.md for correct configuration
2. Retry with documented values
3. Log what was missing for user to add

Endpoint Resolution:

• Production services: Use URLs from TOOLS.md
• Local development: Use localhost only when explicitly testing local
• Automation/cron jobs: Always use production endpoints

---

📅 Sprint Management

Task Creation Rules

• ALWAYS find sprint containing today's date when creating tasks
• If no sprint contains today → use most recent sprint
• Tasks must be in current sprint for automated workers to find them

Auto-Status Feature Needed

• Sprints should auto-update status based on date:
  • planning → active when today >= start_date
  • active → completed when today > end_date
• Prevents manual sprint management overhead

---

🔄 Automation & Cron Jobs

Gantt Board Task Worker (24/7)

• Runs hourly, checks current sprint for open/todo/in-progress tasks
• Works on highest priority task using agent workflow
• Updates with detailed checklist comments
• Uses programmatic login (no stored cookies)

Subagent Status Monitor (20-min)

• Checks every 20 minutes if subagents are running
• If idle: Queries current sprint for available tasks
• Spawns appropriate agents (Alice/Bob/Charlie) to work on tasks
• Ensures continuous progress on backlog

Authentication for Automation

• Cron jobs use programmatic login with stored credentials
• Login every hour keeps session fresh (30-day limit)
• No manual cookie management needed

---

🌐 Web Scraping & Research

X/Twitter Content Extraction

• Primary: Tavily search (fast, clean results)
• Fallback: Scrapling StealthyFetcher (bypasses anti-bot protections)
• DynamicFetcher for complex sites requiring full browser
• Ensures research workflow works even on protected content

Research Workflow Triggers

• User says: "Research this URL", "Save this article", "Summarize and create task"
• Alice-Researcher handles extraction, analysis, task creation
• Verdict determines if implementation plan is attached

---

🏗️ API-Centric CLI Pattern

When building web apps with CLI companions:

Golden Rule

API = single source of truth. CLI = passthrough client only.

Non-Negotiables

• ✅ All business logic lives in API/server code
• ✅ CLI only parses args, calls API, formats output
• ✅ No direct DB calls from CLI
• ✅ If CLI needs new behavior → add to API first
• ✅ Every CLI command has contract tests with mocked API

Why This Matters

Prevents the Gantt Board situation where CLI scripts had duplicate logic, direct DB access, and broke when API changed. Now CLI is a thin client like the web UI.

Skill

/Users/mattbruce/.agents/skills/api-cli-passthrough/SKILL.md

Test Requirements

• API unit tests (domain logic)
• API integration tests (routes)
• CLI contract tests (mocked API transport)

---

🗄️ Shared Supabase Database - CRITICAL: Table Naming Convention

Rule: <project_name>_<table_name> with underscores (NO hyphens)

Why: All Vercel apps share one Supabase project to prevent collisions

Current Prefixes:

• (none) — Gantt Board (legacy - tasks, projects, sprints - no prefix)
• blog_ — Blog Backup (messages, tags)
• mission_control_ — Mission Control (documents, folders)
• heartbeat_ — Heartbeat Monitor (status, logs)

Note: Gantt Board is the legacy app (no prefixes). All NEW apps MUST use prefixes.

Full doc: DB_TABLE_NAMING.md

Remember: Always prefix, always underscores, never abbreviate!

---

🚀 Mission Control Future Vision — Voxyz Inspiration

Date Added: February 22, 2026
Source: X/Twitter Article by Vox (@Voxyz_ai)
Article Title: "I Built an AI Company with OpenClaw + Vercel + Supabase — Two Weeks Later, They Run It Themselves"
Article Date: February 6, 2026

Why This Matters

Vox built a 6-agent autonomous company using the same stack we're using (OpenClaw + Vercel + Supabase). Two weeks after launch, the system runs itself with minimal human intervention. This is the long-term vision for Mission Control.

Vox's Architecture (Reference for Future)

The 6 Agents:

• Minion — Makes decisions
• Sage — Analyzes strategy
• Scout — Gathers intel
• Quill — Writes content
• Xalt — Manages social media
• Observer — Quality checks

The Closed Loop:

Agent proposes idea → Auto-approval check → Create mission + steps 
     ↑                                              ↓
Trigger/Reaction ← Event emitted ← Worker executes

Key Innovations:

1. Single Proposal Service — One function handles ALL proposal creation (no bypassing)
2. Cap Gates — Reject at entry point (don't let queue build up)
3. Reaction Matrix — 30% probability reactions = "feels like a real team"
4. Self-Healing — 30-min stale task detection and recovery

Application to Mission Control

Short-Term (Now): Complete Phases 6-9 as read-only dashboard

Medium-Term: Phase 10 — Daily Mission Generation

• Auto-propose 3 priorities each morning
• Smart triggers for deadlines/blockers
• Simple closed loop: Analyze → Propose → Approve

Long-Term: Phase 11-13 — Full Autonomous Operations

• Agents propose and execute tasks
• Self-healing system
• You monitor, agents run

Key Lessons from Vox's Pitfalls

1. Don't run workers on both VPS and Vercel — Race conditions
2. Always use Proposal Service — Never direct inserts
3. Implement Cap Gates early — Prevent queue buildup
4. Use policy-driven config — Don't hardcode limits
5. Add cooldowns to triggers — Prevent spam

Research Notes

Open Questions:

• Should Matt's agents have "personalities" or stay neutral?
• How much autonomy vs. human approval?
• What happens when agents disagree?

Next Research:

• Follow @Voxyz_ai for updates
• Look for more implementation details beyond the article
• Study OpenClaw autonomous agent patterns
• Search for "OpenClaw closed loop" or "agent operations"

Full Plan Location: /Users/mattbruce/Documents/Projects/OpenClaw/Documents/Mission-Control-Plan.md

Remember: This is the North Star — the ultimate vision for Mission Control. But short-term focus is completing the dashboard first (Phases 6-9).

---

🔄 System Restart & Session Start Requirements (MANDATORY)

Post-Restart Verification Protocol

After ANY OpenClaw gateway restart or new session start:

1. Run the verification checklist: /Users/mattbruce/.openclaw/workspace/post-restart-checklist.md
2. Check each item systematically - don't skip any section
3. Document any failures in the checklist with fixes applied
4. Update the checklist if new issues are discovered
5. Confirm all systems operational before proceeding with work

Why this is critical:

• Subagents, APIs, and configurations require restart to activate
• Prevents "everything worked before restart" assumptions
• Catches configuration issues immediately
• Ensures workflow continuity across sessions

Checklist maintenance:

• Add new verification items as systems are added
• Document common failure modes and their fixes
• Keep current with latest architecture changes
• Reference when subagents fail to spawn or APIs don't work

Triggers for checklist:

• OpenClaw gateway restart (manual or automatic)
• New session start after system changes
• Subagent spawning failures
• API authentication issues
• Configuration changes applied

This is now a CORE OPERATIONAL REQUIREMENT. The checklist ensures system reliability and prevents regression.