WiderWings Recursive Development Protocol (RDP) v0.2

Version: 0.2
Date: March 4, 2026
Author: Bob Wings (Chief of Staff)
Based on: Mark Wings' RDP v0.1 research + Henry/Bob review
Status: Awaiting Henry approval

---

1. Vision

WiderWings operates as an AI-native company where autonomous agents develop, ship, and improve products with minimal human intervention. This protocol defines how.

Core Principle: Every task flows through a pipeline. Every agent knows their role. Every artifact lives in Second Brain. Every handoff is explicit.

---

2. Org Chart

                    Henry (CEO)
                        │
                    Bob (Chief of Staff / Architect)
                        │
            ┌───────────┼───────────────┐
            │           │               │
        Kevin (PM)   Liz (PM)    Mark (Research)
      MedSchools.ai    Hedge       Own Instance
            │           │
    ┌───────┼───────┐   │
    │       │       │   │
   Kai    Atlas   Maya  │
  Front   Back   Content│
    │       │       │   │
    └───┬───┘       │   ├── Kai (shared)
        │           │   ├── Atlas (shared)
      Sage          │   └── Maya (shared)
    QA/Review       │
                    │
               Designer
              (UI/UX Lead)

Role Definitions

Agent	Role	Scope
Bob	Chief of Staff / Architect	Coordination, architecture decisions, process design, Henry interface
Kevin	PM: MedSchools.ai	Owns MedSchools.ai roadmap, sprints, task breakdown, quality
Liz	PM: Hedge	Owns Hedge roadmap, sprints, task breakdown, quality
Kai	Frontend Developer	Svelte/Tailwind/shadcn. Shared across projects via PM assignment
Atlas	Backend Developer	APIs, DB, infrastructure. Shared across projects via PM assignment
Maya	Content Lead	SEO, blog posts, copy, marketing content
Sage	QA Lead / Code Reviewer	Code review, testing, quality gates. Nothing ships without Sage
Designer	UI/UX Design Lead	Visual design, component design, brand assets, design system
Mark	Research & Scraping	Deep research, web scraping, competitive intel. Own OpenClaw instance

Shared Agent Protocol

Kai, Atlas, Maya, and Designer are shared resources. Rules:

1. PMs (Kevin/Liz) request agent time through Bob or directly if non-conflicting
2. If two PMs need the same agent simultaneously, Bob prioritizes based on project urgency
3. Agent context switches require explicit handoff (save state → load new project context)
4. Each agent maintains per-project context files (e.g., kai-medschools-context.md, kai-hedge-context.md)

---

3. Pipeline Phases

Every task flows through these phases. Not every task needs every phase.

Phase	Owner	Input	Output	Gate
1. Brief	PM	Henry directive or agent proposal	Structured brief in Second Brain	PM approval
2. Design	Designer	Brief	Wireframes, component specs, visual direction	PM + Bob review
3. Implement	Kai/Atlas	Brief + Design specs	Working code, committed to branch	Automated tests pass
4. Review	Sage	PR/commit	Review comments, approval/rejection	Max 2 rounds then escalate
5. QA	Sage	Deployed feature	Test results, bug reports	All critical tests pass
6. Ship	PM	Approved, tested feature	Merged to main, deployed	PM sign-off
7. Document	Implementing agent	Shipped feature	Second Brain memory + updated docs	Auto on ship

Skip Paths (Complexity-Based)

Not every task needs the full pipeline:

Task Type	Example	Path
Hotfix	Broken prod, typo, CSS fix	Implement → Ship (Bob or PM can authorize)
Small feature	Add a button, new API field	Brief (1-liner) → Implement → Review → Ship
Medium feature	New page, new endpoint	Brief → Implement → Review → QA → Ship
Large feature	New module, design system	Full pipeline: Brief → Design → Implement → Review → QA → Ship → Document
Research	Market analysis, competitive intel	Brief → Research → Document (no code pipeline)
Content	Blog post, copy	Brief → Write → Review → Publish

Rule of thumb: If it takes < 2 hours, skip Design. If it takes < 30 minutes, skip Review. If it's broken prod, skip everything except the fix.

---

4. Task Lifecycle

All tasks live in Second Brain (brain_tasks table).

States

todo → in_progress → review → done
                  → blocked (needs input/dependency)

Priority Levels

Priority	Response Time	Description
P0	Immediate	Production down, data loss, security breach
P1	Same day	Blocking launch, critical bug, Henry-requested
P2	This sprint	Important feature, significant improvement
P3	Backlog	Nice to have, tech debt, optimization

Task Fields

{
  "title": "Build mobile nav component",
  "description": "Detailed description with acceptance criteria",
  "priority": "P2",
  "status": "todo",
  "agent_id": "kai",
  "project_id": "<project-uuid>",
  "due_date": "2026-03-15",
  "created_by": "kevin",
  "tags": ["frontend", "mobile", "sprint-3"]
}

Brief Requirements by Priority

• P0/P1: Always require a structured brief with acceptance criteria
• P2: Brief required if estimated effort > 2 hours. Otherwise, description field is sufficient
• P3: Description field only. Brief on request

---

5. Handoff Protocol

When an agent completes their phase:

1. Save artifacts to Second Brain (code committed, memory saved, docs updated)
2. Update task status (e.g., in_progress → review)
3. Create next-phase task if needed (e.g., "Review PR #42 for mobile nav")
4. Tag the receiving agent (update agent_id on the new task)
5. Notify PM with one-line status update

Artifact Types by Phase

Phase	Artifact	Where
Brief	Structured brief	Second Brain (type: spec)
Design	Wireframes, component specs	Second Brain (type: spec) + committed files
Implement	Code, PR	Git repo
Review	Review comments	Git PR comments + Second Brain (type: log)
QA	Test results	Second Brain (type: log)
Ship	Deployment confirmation	Second Brain (type: log)
Document	Updated docs	Second Brain (type: spec or reference)

---

6. Quality Gates

Sage's Review Protocol

Sage reviews all code before it ships. Rules:

1. First pass: Check for bugs, security issues, code style, performance
2. Second pass (if needed): Verify fixes from first pass
3. Max 2 rounds. If still not passing after 2 rounds, escalate to Bob
4. Auto-approve: Hotfixes with < 10 lines changed and clear intent can self-approve (PM authorization)

What Sage Checks

• No security vulnerabilities (hardcoded secrets, SQL injection, XSS)
• Error handling (no silent failures)
• Mobile responsiveness (if frontend)
• Performance (no N+1 queries, no unnecessary re-renders)
• Tests exist for critical paths
• Consistent with project patterns

---

7. Agent Infrastructure

OpenClaw Instances

Agent(s)	Machine	Model	Heartbeat
Bob, Kevin, Liz, Kai, Atlas, Maya, Sage, Designer	henryk-ubuntu	Sonnet (all)	Bob: 30min, others: on-demand
Mark	mark-wings-t470s	Sonnet	30min

Heartbeat Schedule

Only Bob runs periodic heartbeats. Other agents are spawned on-demand by Bob or PMs.

Bob's heartbeat checks:

1. Task board — any P0/P1 tasks unassigned?
2. Agent status — any stuck/failed spawns?
3. Git status — any stale branches?
4. Session backup — save current context

Why not stagger all agents: Token cost. 8 agents × 30min heartbeats = massive burn. Spawn-on-demand is cheaper and more predictable.

Agent Spawn Protocol

PMs spawn agents via sessions_spawn:

sessions_spawn(
  task: "Build the X component. Context: [file paths]. Output: commit to [repo].",
  label: "kai-mobile-nav",
  model: "sonnet"
)

Agent Timeout & Failure Rules

• 2-hour timeout: If a task is in_progress for > 2 hours with no artifact (commit, memory, or status update), PM gets alerted
• 3 consecutive failures: If an agent fails 3 tasks in a row, Bob investigates (model issue? bad context? unclear brief?)
• Stuck detection: Heartbeat checks for tasks with no updates in > 4 hours during business hours

---

8. Second Brain as Source of Truth

Project Structure (Final)

Project	Icon	Description
MedSchools.ai	🏥	Medical school guidance platform
Hedge	📈	Algorithmic trading platform
WiderWings	🦅	Company ops, infrastructure, tools (Second Brain, agent network, RDP, design pipeline)
General	📂	Miscellaneous items

Memory Types

Type	Icon	Use For
Decision	🎯	Key decisions with rationale
Spec	📐	Product specs, PRDs, requirements
Research	🔬	Market research, competitive analysis, findings
Architecture	🏗️	System design, infrastructure, tech stack docs
Reference	📚	Setup guides, account info, config details
Process	⚙️	Workflows, protocols, SOPs
Log	📝	Build notes, deployment records, status updates
Lesson	💡	Lessons learned, mistakes, gotchas
Conversation	💬	Important conversations with Henry
Idea	💭	Ideas for future exploration
Task	✅	Work items (prefer brain_tasks table)
Person	👤	Contacts
Secret	🔐	Credentials (encrypted)
Context	📋	Background info that doesn't fit elsewhere

Mandatory Save Rules

Always save immediately:

• Decision made → type: decision
• Spec written → type: spec
• Research completed → type: research
• Lesson learned → type: lesson
• Feature shipped → type: log
• Architecture changed → type: architecture

Save at end of significant work:

• Task completed with notable context
• Important conversation with Henry
• Configuration/setup change → type: reference

---

9. Conflict Resolution

When agents disagree on approach:

1. PM decides for their project (Kevin for MedSchools, Liz for Hedge)
2. Bob decides for cross-project or architecture questions
3. Henry decides for strategy, vision, or major cost decisions
4. Timeout rule: If no resolution in 30 minutes, escalate to next level

Priority Conflicts (Two PMs Need Same Agent)

1. P0/P1 always wins over P2/P3
2. Same priority → project closest to launch wins
3. Still tied → Bob decides
4. Alternative: If conflict is frequent, spawn a second instance of the agent

---

10. Recursive Improvement

The process itself improves over time.

Automated Triggers

1. After every milestone marked "done": Bob creates a brief retro task
2. Weekly (Monday AM): Bob reviews task throughput (completed vs created)
3. Monthly: Full process review — what's working, what's friction

Metrics to Track

Metric	Target	How
Task cycle time (todo → done)	< 4 hours for P2	Second Brain timestamps
Review rounds	≤ 2 per PR	Sage's review logs
Agent utilization	No agent idle with P1+ tasks waiting	Task board scan
Brief quality	< 10% tasks need re-briefing	Track "blocked: unclear brief"
Ship frequency	≥ 1 feature/day across all projects	Git commit frequency

Process Change Protocol

1. Anyone can propose a process change (save as type: idea in Second Brain)
2. Bob evaluates feasibility
3. Henry approves significant changes
4. Bob updates this RDP document
5. All agents get the updated version via their project context files

---

11. Phase 1 Rollout Plan

Start with MedSchools.ai through the full pipeline.

Week 1: Foundation

• Kevin onboarded as PM for MedSchools.ai
• Kevin reads all MedSchools.ai memories in Second Brain
• Kevin creates first sprint backlog (5-8 tasks)
• Bob validates pipeline works end-to-end with one small feature

Week 2: First Full Sprint

• Kevin runs a full sprint: Brief → Design → Implement → Review → QA → Ship
• Sage does first real code review
• Designer does first design spec
• Identify friction points, update RDP

Week 3: Add Hedge

• Liz onboarded as PM for Hedge
• Liz reads all Hedge memories in Second Brain
• Both PMs running parallel sprints
• Bob manages shared agent allocation

Week 4: Steady State

• Process running smoothly across both projects
• Weekly metrics review established
• First process retro completed
• RDP v0.3 drafted with lessons learned

---

12. What This Protocol Does NOT Cover (Yet)

• Deployment automation (CI/CD pipelines, staging environments)
• Cost budgeting (per-agent token spend, monthly caps)
• External communication (how agents interact with users, partners)
• Scaling beyond 2 products (will need when CollegeDojo starts)

These will be added to future RDP versions as we encounter the need.

---

Appendix A: Project IDs (for task/memory creation)

Project	UUID
MedSchools.ai	799d218b-8193-4124-93ea-1407ebe53cb4
Hedge	6a94bcec-ae12-4ebb-b0f7-5bcb7f9a5cb9
WiderWings	ba876fd3-bc76-4670-a656-614a4853bd54
General	00000000-0000-0000-0000-000000000001

Appendix B: Changes from v0.1

Item	v0.1	v0.2	Reason
Designer agent	Not included	Added	Henry: MedSchools.ai design needs help before launch
Model selection	Sonnet for complex, Haiku for routine	Sonnet for all (for now)	Henry: stay with Sonnet
Rollout	All projects simultaneously	MedSchools.ai first, then Hedge	Prove pipeline works before scaling
Brief requirements	All tasks need structured brief	P0/P1 always, P2 only if > 2hrs, P3 never	Reduces overhead for small tasks
Heartbeat schedule	All agents staggered	Bob only, others on-demand	Token cost optimization
Agent timeout	Not defined	2-hour timeout, 3-failure investigation	Prevents stuck tasks
Conflict resolution	"Bob handles it"	Defined escalation: PM → Bob → Henry	Clear process
Memory types	10 types	14 types (added architecture, reference, log, process)	"Context" was too broad
Projects	6 projects	4 projects (MedSchools.ai, Hedge, WiderWings, General)	Cleaner organization