Team Structure

Four Teams, One Manager

Team	Purpose	Agents
Research	Theory, math, literature, proofs	research-dev/rev
Dev	Architecture + implementation	architect-dev/rev, code-dev/rev
KB	Documentation: cards, API docs, tex	kb-dev/rev
QA	Full regression, full benchmark	benchmark

Plus shadow as a validation mode (not a standing team).

             User (co-plans, gates, reviews math)
               |
             Manager (owns kanban, coordinates)
               |
    +----------+----------+----------+
    |          |          |          |
 Research     Dev        KB         QA
  dev/rev   arch d/r   dev/rev   benchmark
            code d/r

Agent Roster

Research Team

Agent	Role	Type
research-developer	Theory, math, literature, proofs	Developer
research-reviewer	Challenge research claims, verify proofs	Reviewer

Research produces idea cards and tex drafts that land in KB as informal artifacts (no code backing yet).

Dev Team

Agent	Role	Type
architect-developer	Design, abstraction layers, refactoring plans	Developer
architect-reviewer	Challenge architecture, check feasibility	Reviewer
code-developer	Implementation + smoke test	Developer
code-reviewer	Block on issues + small reg test with early stop	Reviewer

KB Team

Agent	Role	Type
kb-developer	Cards, API docs (Doxygen/Sphinx), math docs, index, fine-tune tex	Developer
kb-reviewer	Board view, scoring, staleness detection	Reviewer

KB is the project's shared knowledge. All teams feed into it:

Research → idea cards, tex drafts
Dev → @code-change tags → formal cards + API docs
KB-dev fine-tunes tex after cards and API docs are done

QA Team

Agent	Role	Type
benchmark	Full regression, full benchmark, performance reports	Standalone

QA runs the full test suite and benchmark. Distinct from code-reviewer's small reg test with early stop.

Shadow (validation mode)

Agent	Role	Type
shadow-developer	Reimplement modules from KB only (no source access)	Developer
shadow-reviewer	Compare reimplementation against original, score transfer	Reviewer

Shadow is activated on demand, not always running.

Coordinator

Agent	Role	Type
manager	Owns kanban, coordinates all teams, co-plans with user	Coordinator

Accountability Chain

Every agent has a reviewer. The manager's reviewer is the user.

User (co-plans, gates every phase, reviews tex for math)
  └── Manager (owns kanban, proposes, reports)
        ├── Research team (dev/rev)
        ├── Dev team (arch dev/rev, code dev/rev)
        ├── KB team (dev/rev)
        ├── QA team (benchmark)
        └── Shadow mode (dev/rev, on demand)

Reviewers are blockers

Without this, developers prefer deliverables over safety and performance. Reviewers also run small regression tests (early stop). Only High-severity findings are hard blocks; Medium is "should fix" but doesn't block.

Decisions reserved for the user:

Phase transitions (user gates every phase)
Merge decisions (shadow blocks)
Baseline updates
Escalated disputes (medium/high severity)
Release gates
Scope changes mid-sprint
HALT and rollback decisions
Math review (tex documents)

Reviewer vs QA Testing

	Code-reviewer (dev team)	QA (benchmark)
Test set	Small	Full
Early stop	Yes (fail fast)	No (complete run)
When	Every code change	Pre-release / on demand
Blocks	Merge to branch	Release

Team Pairs

Manager:      user (co-plans, gates)   ←→  manager (owns kanban, reports)
Research:     research-developer       ←→  research-reviewer
Architecture: architect-developer      ←→  architect-reviewer
Code:         code-developer           ←→  code-reviewer
KB:           kb-developer             ←→  kb-reviewer
QA:           benchmark (standalone)
Shadow:       shadow-developer         ←→  shadow-reviewer

Routing

Request type	Primary	Reviewer
Prove / derive / survey	research-dev	research-rev
Where to implement / refactor	architect-dev	architect-rev
Implement / fix bug	code-dev	code-rev
Write card / annotate / fine-tune tex	kb-dev	kb-rev
Full benchmark / pre-release	benchmark	---
Review KB coverage	kb-rev	---
Validate KB transfer quality	shadow-dev	shadow-rev
Complex multi-team request	manager decomposes	all relevant

Escalation Policy

When a developer and reviewer disagree:

Severity	Resolution
Minor (style, naming)	Developer decides, reviewer notes it
Medium (design choice)	Manager presents both sides to user; user decides
High (correctness, safety)	Reviewer has veto. Must resolve before proceeding.

Warning

In adversarial environments, the default is the reviewer's position. The cost of missing a real problem outweighs the cost of an extra revision.

Owner Abbreviations

Short	Agent
`res-dev`	research-developer
`res-rev`	research-reviewer
`arch-dev`	architect-developer
`arch-rev`	architect-reviewer
`code-dev`	code-developer
`code-rev`	code-reviewer
`kb-dev`	kb-developer
`kb-rev`	kb-reviewer
`bench`	benchmark (QA)
`shad-dev`	shadow-developer
`shad-rev`	shadow-reviewer
`mgr`	manager