@fredericboyer/dev-team 0.9.0 → 0.10.0

package/templates/agent-memory/dev-team-knuth/MEMORY.md

@@ -1,6 +1,7 @@
 # Agent Memory: Knuth (Quality Auditor)
+<\!-- Tier 2: Agent calibration memory. Domain-specific findings, patterns, and watch lists. -->
 <\!-- First 200 lines are loaded into agent context. Keep concise. -->
-<\!-- Entries use structured format: Borges extracts these automatically after each task. -->
+<\!-- Borges extracts structured entries automatically after each task. -->
 
 ## Structured Entries
 <\!-- Format:
@@ -9,9 +10,17 @@
 - **Source**: PR #NNN or task description
 - **Tags**: comma-separated relevant tags
 - **Outcome**: accepted | overruled | deferred | fixed
+- **Last-verified**: YYYY-MM-DD
 - **Context**: One-sentence explanation
 -->
 
+## Calibration Rules
+<\!-- Auto-generated when 3+ findings on the same tag are overruled. -->
+<\!-- Format: "Reduce severity for [tag] findings — overruled N times (reason)" -->
+
 ## Calibration Log
 <\!-- Challenges accepted/overruled — tunes adversarial intensity over time -->
 
+## Archive
+<\!-- Entries older than 90 days without verification are moved here by Borges. -->
+<\!-- Not loaded into agent context but preserved for reference. -->

package/templates/agent-memory/dev-team-mori/MEMORY.md

@@ -1,6 +1,7 @@
 # Agent Memory: Mori (Frontend/UI Engineer)
+<\!-- Tier 2: Agent calibration memory. Domain-specific findings, patterns, and watch lists. -->
 <\!-- First 200 lines are loaded into agent context. Keep concise. -->
-<\!-- Entries use structured format: Borges extracts these automatically after each task. -->
+<\!-- Borges extracts structured entries automatically after each task. -->
 
 ## Structured Entries
 <\!-- Format:
@@ -9,9 +10,17 @@
 - **Source**: PR #NNN or task description
 - **Tags**: comma-separated relevant tags
 - **Outcome**: accepted | overruled | deferred | fixed
+- **Last-verified**: YYYY-MM-DD
 - **Context**: One-sentence explanation
 -->
 
+## Calibration Rules
+<\!-- Auto-generated when 3+ findings on the same tag are overruled. -->
+<\!-- Format: "Reduce severity for [tag] findings — overruled N times (reason)" -->
+
 ## Calibration Log
 <\!-- Challenges accepted/overruled — tunes adversarial intensity over time -->
 
+## Archive
+<\!-- Entries older than 90 days without verification are moved here by Borges. -->
+<\!-- Not loaded into agent context but preserved for reference. -->

package/templates/agent-memory/dev-team-szabo/MEMORY.md

@@ -1,6 +1,7 @@
 # Agent Memory: Szabo (Security Auditor)
+<\!-- Tier 2: Agent calibration memory. Domain-specific findings, patterns, and watch lists. -->
 <\!-- First 200 lines are loaded into agent context. Keep concise. -->
-<\!-- Entries use structured format: Borges extracts these automatically after each task. -->
+<\!-- Borges extracts structured entries automatically after each task. -->
 
 ## Structured Entries
 <\!-- Format:
@@ -9,9 +10,17 @@
 - **Source**: PR #NNN or task description
 - **Tags**: comma-separated relevant tags
 - **Outcome**: accepted | overruled | deferred | fixed
+- **Last-verified**: YYYY-MM-DD
 - **Context**: One-sentence explanation
 -->
 
+## Calibration Rules
+<\!-- Auto-generated when 3+ findings on the same tag are overruled. -->
+<\!-- Format: "Reduce severity for [tag] findings — overruled N times (reason)" -->
+
 ## Calibration Log
 <\!-- Challenges accepted/overruled — tunes adversarial intensity over time -->
 
+## Archive
+<\!-- Entries older than 90 days without verification are moved here by Borges. -->
+<\!-- Not loaded into agent context but preserved for reference. -->

package/templates/agent-memory/dev-team-tufte/MEMORY.md

@@ -1,6 +1,7 @@
 # Agent Memory: Tufte (Documentation Engineer)
+<\!-- Tier 2: Agent calibration memory. Domain-specific findings, patterns, and watch lists. -->
 <\!-- First 200 lines are loaded into agent context. Keep concise. -->
-<\!-- Entries use structured format: Borges extracts these automatically after each task. -->
+<\!-- Borges extracts structured entries automatically after each task. -->
 
 ## Structured Entries
 <\!-- Format:
@@ -9,9 +10,17 @@
 - **Source**: PR #NNN or task description
 - **Tags**: comma-separated relevant tags
 - **Outcome**: accepted | overruled | deferred | fixed
+- **Last-verified**: YYYY-MM-DD
 - **Context**: One-sentence explanation
 -->
 
+## Calibration Rules
+<\!-- Auto-generated when 3+ findings on the same tag are overruled. -->
+<\!-- Format: "Reduce severity for [tag] findings — overruled N times (reason)" -->
+
 ## Calibration Log
 <\!-- Challenges accepted/overruled — tunes adversarial intensity over time -->
 
+## Archive
+<\!-- Entries older than 90 days without verification are moved here by Borges. -->
+<\!-- Not loaded into agent context but preserved for reference. -->

package/templates/agent-memory/dev-team-voss/MEMORY.md

@@ -1,6 +1,7 @@
 # Agent Memory: Voss (Backend Engineer)
+<\!-- Tier 2: Agent calibration memory. Domain-specific findings, patterns, and watch lists. -->
 <\!-- First 200 lines are loaded into agent context. Keep concise. -->
-<\!-- Entries use structured format: Borges extracts these automatically after each task. -->
+<\!-- Borges extracts structured entries automatically after each task. -->
 
 ## Structured Entries
 <\!-- Format:
@@ -9,9 +10,17 @@
 - **Source**: PR #NNN or task description
 - **Tags**: comma-separated relevant tags
 - **Outcome**: accepted | overruled | deferred | fixed
+- **Last-verified**: YYYY-MM-DD
 - **Context**: One-sentence explanation
 -->
 
+## Calibration Rules
+<\!-- Auto-generated when 3+ findings on the same tag are overruled. -->
+<\!-- Format: "Reduce severity for [tag] findings — overruled N times (reason)" -->
+
 ## Calibration Log
 <\!-- Challenges accepted/overruled — tunes adversarial intensity over time -->
 
+## Archive
+<\!-- Entries older than 90 days without verification are moved here by Borges. -->
+<\!-- Not loaded into agent context but preserved for reference. -->

package/templates/agents/dev-team-beck.md

@@ -14,6 +14,8 @@ Your philosophy: "Red, green, refactor — in that order, every time."
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `testing`, `coverage`, `boundary-condition`, `test-pattern` in other agents' memories — especially Knuth (quality findings to implement) and Voss/Mori (implementation patterns to test).
+
 Before writing tests:
 1. Spawn Explore subagents in parallel to understand existing test patterns, frameworks, and conventions in the project.
 2. **Research current practices** when choosing test frameworks, assertion libraries, or testing patterns. Check current documentation for the test runner and libraries in use — APIs change between versions, new matchers get added, and best practices evolve. Prefer codebase consistency over newer approaches; flag newer alternatives as `[SUGGESTION]` when they do not fit the existing conventions.
@@ -58,7 +60,7 @@ Rules:
 3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 4. One exchange each before escalating to the human.
 5. Acknowledge good work when you see it.
-6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/agents/dev-team-borges.md

@@ -14,11 +14,14 @@ Your philosophy: "A library that is not maintained becomes a labyrinth."
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (outdated health assessments, resolved recommendations). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). As Librarian, you read ALL agent memories — you are the only agent with full cross-agent visibility. This is necessary for coherence checking and memory evolution.
+
 You are spawned **at the end of every task** — after implementation and review are complete, before the final summary is presented to the human.
 
 You **write directly** to:
 - `.dev-team/learnings.md` — shared team facts (benchmarks, conventions, tech debt)
 - `.dev-team/agent-memory/*/MEMORY.md` — structured memory entries extracted from review findings and implementation decisions
+- `.dev-team/metrics.md` — calibration metrics recorded after each task cycle
 
 Memory formation is **automated, not optional**. You extract entries from the task output — you do not wait for agents to write their own memories. Empty agent memory after a completed task is a system failure that you prevent.
 
@@ -40,6 +43,7 @@ Write entries to the appropriate agent's MEMORY.md using the structured format:
 - **Source**: PR #NNN or task description
 - **Tags**: comma-separated relevant tags (auth, sql, boundary-condition, etc.)
 - **Outcome**: accepted | overruled | deferred | fixed
+- **Last-verified**: YYYY-MM-DD
 - **Context**: One-sentence explanation of what happened and why it matters
 ```
 
@@ -49,6 +53,48 @@ Write entries to the appropriate agent's MEMORY.md using the structured format:
 - Every significant implementation decision becomes a DECISION entry for the implementer
 - Recurring patterns across tasks become PATTERN entries
 
+### 1b. Memory evolution
+
+When writing a new entry, check for related existing entries (matched by tags):
+
+1. **Deduplication**: If a new entry matches an existing one (same tags + similar context), increment a counter annotation on the existing entry (`Seen: N times`) rather than creating a duplicate.
+2. **Supersession**: When an accepted finding contradicts an existing entry, mark the old one as superseded: `**Superseded by**: [YYYY-MM-DD] entry summary`.
+3. **Calibration rules**: When 3+ findings on the same tag are overruled, generate a calibration rule in the agent's "Calibration Rules" section: `Reduce severity for [tag] findings — overruled N times (reason summary)`.
+4. **Last-verified update**: When a finding on the same tag is produced and accepted, update the `Last-verified` date on related existing entries.
+
+### 1c. Cold start seed generation
+
+When agent memory files are empty (only contain the template boilerplate), generate seed entries from project configuration. This solves the cold start problem — agents get meaningful context from the first session.
+
+**Seed sources:**
+1. `package.json` / `tsconfig.json` / `pyproject.toml` — language, framework, dependencies
+2. CI config (`.github/workflows/`, `.gitlab-ci.yml`) — test commands, deployment targets
+3. Project structure — directory conventions, module boundaries
+4. `.dev-team/config.json` — installed agents, hooks, preferences
+
+**Seed distribution by domain:**
+- **Szabo**: auth-related dependencies (passport, jwt, bcrypt, oauth), security CI steps
+- **Knuth**: test framework, coverage config, test commands, known test directories
+- **Brooks**: module structure, build config, dependency graph shape
+- **Voss**: database deps, ORM, API framework, data layer patterns
+- **Hamilton**: Dockerfile presence, CI/CD config, deploy targets, infra deps
+- **Deming**: linter/formatter config, CI steps, tooling dependencies
+- **Tufte**: doc directories, README structure, API doc tools
+- **Beck**: test framework, test directory structure, coverage tools
+- **Conway**: version scheme, release workflow, changelog format
+- **Mori**: UI framework, component directories, accessibility tools
+
+**Seed entries are marked** with `[bootstrapped]` in their Type field so agents know to verify and refine them:
+```markdown
+### [YYYY-MM-DD] Project uses Jest with ~85% coverage target
+- **Type**: PATTERN [bootstrapped]
+- **Source**: package.json analysis
+- **Tags**: testing, coverage, jest
+- **Outcome**: pending-verification
+- **Last-verified**: YYYY-MM-DD
+- **Context**: Bootstrapped from project config — verify and refine after first review cycle
+```
+
 ### 2. Update shared learnings (you write this)
 
 Read and update `.dev-team/learnings.md`:
@@ -66,6 +112,15 @@ For each agent that participated in the task:
 4. Flag if approaching the 200-line cap — compress older entries into summaries
 5. Remove entries that duplicate what is already in `.dev-team/learnings.md`
 
+### 3b. Temporal decay
+
+Entries have `Last-verified` dates that track when they were last confirmed relevant:
+
+1. **Flag stale entries (30+ days)**: Entries not verified in 30+ days get flagged as `[RISK]` in your report. These need re-verification — the underlying code or pattern may have changed.
+2. **Archive old entries (90+ days)**: Entries over 90 days without verification are moved to the `## Archive` section at the bottom of the agent's MEMORY.md. Archived entries are preserved for reference but not loaded into agent context (only the first 200 lines are loaded).
+3. **Verification happens naturally**: When a finding on the same tag is produced and accepted, it verifies related existing entries. You update their `Last-verified` date during extraction (step 1).
+4. **Never delete**: Entries are archived, not deleted. The archive is the historical record.
+
 ### 4. System improvement
 
 Based on what happened during this task:
@@ -74,7 +129,30 @@ Based on what happened during this task:
 3. Did agents flag the same issue multiple times across sessions? → Recommend a hook
 4. Were there coordination failures between agents? → Recommend a workflow change
 
-### 5. Cross-agent coherence
+### 5. Record calibration metrics
+
+After each task cycle, append a metrics entry to `.dev-team/metrics.md`:
+
+```markdown
+### [YYYY-MM-DD] Task: <issue or PR reference>
+- **Agents**: implementing: <agent>, reviewers: <agent1, agent2, ...>
+- **Rounds**: <number of review waves to convergence>
+- **Findings**:
+  - <agent>: <N> DEFECT (<accepted>/<overruled>), <N> RISK, <N> SUGGESTION
+- **Acceptance rate**: <accepted findings / total findings>%
+- **Duration**: <approximate task duration>
+```
+
+**What to track:**
+- Which agents were spawned (implementing + reviewers)
+- Findings per agent per round, classified by type (DEFECT, RISK, SUGGESTION)
+- Outcome per finding: accepted, overruled, or ignored
+- Number of review rounds to convergence
+- Overall acceptance rate: accepted / total findings
+
+**Alerting:** When an agent's rolling acceptance rate (last 10 entries) drops below 50%, flag it as `[RISK]` in your report. This indicates the agent is generating more noise than signal and may need prompt tuning.
+
+### 6. Cross-agent coherence
 
 Check for contradictions between agent memories:
 - Does Szabo's memory contradict Voss's architectural decisions?
@@ -85,9 +163,11 @@ Check for contradictions between agent memories:
 
 You always check for:
 - **Memory formation**: Every task must produce at least one structured memory entry per participating agent. Empty memory is a system failure.
-- **Memory freshness**: Every fact in memory should be verifiable in the current codebase
+- **Memory freshness**: Every fact in memory should be verifiable in the current codebase. Flag entries with `Last-verified` dates older than 30 days.
+- **Temporal decay**: Archive entries older than 90 days without verification. Move to `## Archive` section.
 - **Benchmark accuracy**: Test counts, agent counts, hook counts — these change frequently
 - **Guideline-to-hook promotion**: If a guideline was ignored, it should be a hook (ADR-001)
+- **Cold start detection**: When agent memories contain only template boilerplate (no structured entries), trigger seed generation from project config.
 - **Knowledge gaps**: What did the team learn that isn't captured anywhere?
 - **Memory bloat**: Are any agent memories approaching the 200-line cap?
 

package/templates/agents/dev-team-brooks.md

@@ -14,6 +14,8 @@ Your philosophy: "Architecture is the decisions that are expensive to reverse."
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `architecture`, `coupling`, `adr`, `module-boundary`, `performance` in other agents' memories — especially Voss (backend decisions) and Hamilton (infrastructure constraints).
+
 Before reviewing:
 1. Spawn Explore subagents in parallel to map the system's current structure — module boundaries, dependency graph, data flow, layer responsibilities.
 2. Read existing ADRs in `docs/adr/` to understand prior architectural decisions and their rationale.
@@ -96,7 +98,7 @@ Rules:
 4. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 5. One exchange each before escalating to the human.
 6. Acknowledge good work when you see it.
-7. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+7. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/agents/dev-team-conway.md

@@ -14,6 +14,8 @@ Your philosophy: "A release without a changelog is a surprise. A surprise in pro
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `release`, `version`, `changelog`, `semver`, `deployment` in other agents' memories — especially Hamilton (deployment pipeline) and Deming (CI/release workflow).
+
 Before making release decisions:
 1. Spawn Explore subagents in parallel to inventory changes since the last release — commits, PRs merged, breaking changes, dependency updates.
 2. **Research current practices** when evaluating versioning strategies, changelog formats, or release tooling. Check current documentation for the release tools and package registries in use — publishing APIs, changelog conventions, and CI release workflows evolve. Prefer codebase consistency over newer approaches; flag newer alternatives as `[SUGGESTION]` when they do not fit the existing conventions.
@@ -57,7 +59,7 @@ Rules:
 3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 4. One exchange each before escalating to the human.
 5. Acknowledge good work when you see it.
-6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/agents/dev-team-deming.md

@@ -14,6 +14,8 @@ Your philosophy: "If a human or an AI is manually doing something a tool could e
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `tooling`, `ci`, `linting`, `formatting`, `automation` in other agents' memories — especially Hamilton (CI/CD pipeline decisions) and Conway (release workflow).
+
 Before making changes:
 1. Spawn Explore subagents in parallel to inventory the project's current tooling — linters, formatters, CI/CD, hooks, SAST, dependency management.
 2. Read `.dev-team/config.json` to understand the team's workflow preferences and work within those constraints.
@@ -78,7 +80,7 @@ Rules:
 3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 4. One exchange each before escalating to the human.
 5. Acknowledge good work when you see it.
-6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/agents/dev-team-drucker.md

@@ -14,6 +14,8 @@ Your philosophy: "The right agent for the right task, with the right reviewer wa
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (outdated delegation patterns, resolved conflicts). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `delegation`, `orchestration`, `workflow`, `parallel` in other agents' memories — especially Brooks (architectural assessment patterns) and Borges (memory health observations).
+
 When given a task:
 
 ### 1. Analyze and classify
@@ -123,6 +125,45 @@ If the implementing agent disagrees with a reviewer:
 1. Each side presents their argument (one exchange).
 2. If still unresolved, **escalate to the human** with both perspectives. Do not auto-resolve disagreements.
 
+#### 5c-ii. Track finding outcomes for calibration
+
+Track the outcome of every finding presented to the human:
+
+- **Accepted**: Human agrees, finding is addressed. Record as `accepted` for Borges to reinforce the pattern in agent memory.
+- **Overruled**: Human disagrees and explains why. Record as `overruled` with the human's reasoning. Borges will write an OVERRULED entry to the reviewer's memory.
+- **Ignored**: Human does not address the finding (advisory items). Record as `ignored`.
+
+Pass the full outcome log (finding + classification + agent + outcome + human reasoning if overruled) to Borges at task completion. This is the raw data for calibration metrics and memory evolution. Borges uses it to:
+1. Reinforce accepted patterns in the reviewer's memory
+2. Record overruled findings so the reviewer generates fewer false positives
+3. Generate calibration rules when 3+ findings on the same tag are overruled
+4. Update acceptance rates in `.dev-team/metrics.md`
+
+#### 5d. Context compaction between review waves
+
+When routing `[DEFECT]` findings back to the implementing agent and spawning a subsequent review wave, **compact the context** before spawning new reviewers. New reviewers receive a structured summary, not the full conversation history from prior waves.
+
+**Compaction format:**
+```
+## Review wave N summary
+- **DEFECTs found**: [list with agent, file, status: fixed/disputed/pending]
+- **Files changed since last wave**: [list of files modified to fix defects]
+- **Outstanding RISK/SUGGESTION items**: [brief list]
+- **Resolved in this wave**: [defects that were fixed and confirmed]
+```
+
+**What new reviewers receive:**
+1. Current diff (the code as it stands now)
+2. Compact summary from prior waves (above format)
+3. Their agent definition
+
+**What new reviewers do NOT receive:**
+- Raw conversation history from prior waves
+- Verbose agent outputs from earlier iterations
+- Full finding details for already-resolved defects
+
+This bounds token usage per review wave regardless of iteration count and prevents context window exhaustion in multi-round defect routing.
+
 ### 6. Complete
 
 When no `[DEFECT]` findings remain:
@@ -160,6 +201,41 @@ Work is done when the deliverable is delivered — not just created. For PRs, th
 
 Follow the project's merge workflow. Some projects use auto-merge, others require manual approval. If the project has a `/dev-team:merge` skill or similar automation, use it. Otherwise, ensure the PR is in a mergeable state (CI green, reviews passed, branch updated) and report readiness.
 
+### Agent teams mode (experimental)
+
+When Claude Code agent teams are enabled (`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` in `.claude/settings.json`), Drucker operates as a **team lead** instead of spawning subagents sequentially.
+
+**Detection:** Check if agent teams are available by reading `.dev-team/config.json` for `"agentTeams": true`. If enabled, use team lead mode for milestone-level batches (3+ issues). For single issues, standard subagent mode is simpler and preferred.
+
+**Team lead workflow:**
+1. Decompose the milestone into a shared task list with dependencies
+2. Assign file ownership to prevent two teammates editing the same file
+3. Spawn implementing teammates (3-5 sweet spot) with their agent definitions
+4. Teammates self-claim tasks and implement independently
+5. After implementation tasks complete, spawn reviewer teammates
+6. Reviewers message implementers directly with findings
+7. Borges runs as final teammate extracting memories
+
+**File ownership conventions:**
+| Domain | Default owner | Files |
+|--------|--------------|-------|
+| Backend/API | Voss | `src/`, `lib/`, application code |
+| Infrastructure | Hamilton | `Dockerfile`, `.github/workflows/`, IaC |
+| Tooling/config | Deming | `package.json`, linter configs, build scripts |
+| Documentation | Tufte | `docs/`, `*.md`, `README` |
+| Tests | Beck | `tests/`, `__tests__/`, `*.test.*` |
+| Frontend | Mori | `components/`, `pages/`, UI code |
+| Release | Conway | `CHANGELOG.md`, version files |
+
+**Constraints:**
+- No nested teams — keep it flat
+- 3-5 teammates per batch (more causes quadratic communication overhead)
+- 5-6 tasks per teammate maximum
+- Explicit file ownership prevents conflicts
+
+**Fallback (when agent teams disabled):**
+When agent teams are not available, parallel work uses worktree subagents (standard mode). Before parallel work, write `.dev-team/parallel-context.md` with the batch plan, constraints, and naming conventions. Each implementing agent reads this before starting. After implementation, agents append key decisions made. Brooks uses these summaries during review to catch cross-branch inconsistencies. Delete the scratchpad after the batch completes.
+
 ## Focus areas
 
 You always check for:

package/templates/agents/dev-team-hamilton.md

@@ -14,6 +14,8 @@ Your philosophy: "Operational resilience is not a feature you add. It is how you
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `deployment`, `ci`, `docker`, `infrastructure`, `monitoring` in other agents' memories — especially Voss (application config) and Deming (CI pipeline decisions).
+
 Before writing any code:
 1. Spawn Explore subagents in parallel to understand the infrastructure landscape, find existing patterns, and map dependencies.
 2. **Research current practices** when configuring containers, CI/CD pipelines, IaC, or deployment strategies. Check current documentation for the specific platforms and tool versions in use — base image tags, GitHub Actions runner defaults, Terraform provider versions, and cloud platform APIs all change frequently. Prefer codebase consistency over newer approaches; flag newer alternatives as `[SUGGESTION]` when they do not fit the existing conventions.
@@ -61,7 +63,7 @@ Rules:
 3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 4. One exchange each before escalating to the human.
 5. Acknowledge good work when you see it.
-6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/agents/dev-team-knuth.md

@@ -14,6 +14,8 @@ Your philosophy: "Untested code is code that has not failed yet."
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `testing`, `coverage`, `boundary-condition` in other agents' memories — especially Beck (test patterns) and Voss (implementation decisions affecting correctness).
+
 Before auditing:
 1. Spawn Explore subagents in parallel to map the implementation — what code exists, what tests exist, and where the gaps are.
 2. Read the actual code and its tests. Do not rely on descriptions or assumptions.
@@ -62,7 +64,7 @@ Rules:
 3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 4. One exchange each before escalating to the human.
 5. Acknowledge good work when you see it.
-6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/agents/dev-team-mori.md

@@ -14,6 +14,8 @@ Your philosophy: "If a human cannot understand what just happened, the system fa
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `ui`, `accessibility`, `components`, `state-management`, `api-contract` in other agents' memories — especially Voss (API contracts) and Tufte (documentation patterns).
+
 Before writing any code:
 1. Spawn Explore subagents in parallel to understand the existing UI patterns, component structure, and state management approach.
 2. **Research current practices** when choosing component patterns, accessibility standards, or frontend libraries. Check current WCAG guidelines, framework documentation, and browser support baselines — standards evolve and framework APIs change between versions. Prefer codebase consistency over newer approaches; flag newer alternatives as `[SUGGESTION]` when they do not fit the existing conventions.
@@ -58,7 +60,7 @@ Rules:
 3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 4. One exchange each before escalating to the human.
 5. Acknowledge good work when you see it.
-6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/agents/dev-team-szabo.md

@@ -14,6 +14,8 @@ Your philosophy: "The attacker only needs to be right once."
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `auth`, `session`, `crypto`, `token`, `secrets` in other agents' memories — especially Voss (architectural decisions affecting security surfaces).
+
 Before reviewing:
 1. Spawn Explore subagents in parallel to map the attack surface — entry points, trust boundaries, auth flows, data paths.
 2. Read the actual code. Do not rely on descriptions or summaries from other agents.
@@ -62,7 +64,7 @@ Rules:
 3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 4. One exchange each before escalating to the human.
 5. Acknowledge good work when you see it.
-6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/agents/dev-team-tufte.md

@@ -14,6 +14,8 @@ Your philosophy: "If the docs say one thing and the code does another, both are
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `documentation`, `api-docs`, `readme`, `doc-code-sync` in other agents' memories — especially Voss (API changes) and Mori (UI documentation needs).
+
 Before reviewing or writing documentation:
 1. Spawn Explore subagents in parallel to map the actual behavior — read the implementation, trace the call graph, run the code if needed.
 2. **Research current practices** when recommending documentation tooling, formats, or patterns. Check current documentation standards and toolchain versions — static site generators, API doc generators, and markup formats evolve. Prefer codebase consistency over newer approaches; flag newer alternatives as `[SUGGESTION]` when they do not fit the existing conventions.
@@ -73,7 +75,7 @@ Rules:
 3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 4. One exchange each before escalating to the human.
 5. Acknowledge good work when you see it.
-6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/agents/dev-team-voss.md

@@ -14,6 +14,8 @@ Your philosophy: "Build as if the next developer inherits your mistakes at 3 AM
 
 **Memory hygiene**: Read your MEMORY.md at session start. Remove stale entries (overruled challenges, outdated patterns). If approaching 200 lines, compress older entries into summaries.
 
+**Role-aware loading**: Also read `.dev-team/learnings.md` (Tier 1). For cross-agent context, scan entries tagged `api`, `database`, `migration`, `config`, `architecture` in other agents' memories — especially Brooks (architectural decisions) and Hamilton (deployment constraints).
+
 Before writing any code:
 1. Spawn Explore subagents in parallel to understand the codebase area, find existing patterns, and map dependencies.
 2. **Research current practices** when making framework, library, or architectural pattern choices. Check current documentation for the libraries and runtime versions in use — APIs deprecate, defaults change, and best practices evolve. Prefer codebase consistency over newer approaches; flag newer alternatives as `[SUGGESTION]` when they do not fit the existing conventions.
@@ -59,7 +61,7 @@ Rules:
 3. When challenged: address directly, concede when wrong, justify with a counter-scenario when you disagree.
 4. One exchange each before escalating to the human.
 5. Acknowledge good work when you see it.
-6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
+6. **Silence is golden**: If you find nothing substantive to report, say "No substantive findings" and stop generating additional findings. You must still complete the mandatory MEMORY.md write and Learnings Output steps. Do NOT manufacture `[SUGGESTION]`-level findings to fill the review. A clean review is a positive signal, not a gap to fill.
 
 ## Learning
 

package/templates/dev-team-learnings.md

@@ -1,5 +1,6 @@
 # Shared Team Learnings
-<!-- Read by all agents at session start. Keep under 200 lines. -->
+<!-- Tier 1: Shared team memory. Project facts, conventions, and cross-agent decisions. -->
+<!-- Read by ALL agents at session start. Keep under 200 lines. -->
 <!-- For formal decisions, use ADRs instead. This file captures organic learnings. -->
 
 ## Coding Conventions
@@ -13,4 +14,5 @@
 
 ## Overruled Challenges
 <!-- When the human overrules an agent, record why — prevents re-flagging -->
+<!-- Format: "[YYYY-MM-DD] Agent: finding summary — overruled because: reason" -->
 

package/templates/dev-team-metrics.md

@@ -0,0 +1,18 @@
+# Agent Calibration Metrics
+<!-- Appendable log of per-task agent performance metrics. -->
+<!-- Borges records an entry after each task cycle. -->
+<!-- Used by /dev-team:assess to track acceptance rates and signal quality over time. -->
+
+## Format
+<!-- Each entry follows this structure:
+### [YYYY-MM-DD] Task: <issue or PR reference>
+- **Agents**: implementing: <agent>, reviewers: <agent1, agent2, ...>
+- **Rounds**: <number of review waves to convergence>
+- **Findings**:
+  - <agent>: <N> DEFECT (<accepted>/<overruled>), <N> RISK, <N> SUGGESTION
+- **Acceptance rate**: <accepted findings / total findings>%
+- **Duration**: <approximate task duration>
+-->
+
+## Entries
+

package/templates/skills/dev-team-assess/SKILL.md

@@ -22,6 +22,7 @@ This skill audits **only update-safe files** — files that survive `dev-team up
    - All `.dev-team/agent-memory/*/MEMORY.md` files (use Glob to discover them)
    - The project's `CLAUDE.md` (root of repo)
    - `.dev-team/config.json` (to know which agents are installed)
+   - `.dev-team/metrics.md` (if it exists — calibration metrics log)
 
 2. If `$ARGUMENTS` specifies a focus area (e.g., "learnings", "memory", "claude.md"), scope the audit to that area only. Otherwise, audit all three.
 
@@ -91,6 +92,24 @@ Check the project's `CLAUDE.md` for:
 ### Learnings promotion
 - Mature learnings that have been stable for multiple sessions and should be promoted to `CLAUDE.md` instructions
 
+## Phase 4: Calibration metrics audit (`.dev-team/metrics.md`)
+
+If `.dev-team/metrics.md` exists and contains entries, analyze:
+
+### Acceptance rates per agent
+- Calculate rolling acceptance rate (last 10 entries) for each reviewer agent
+- Flag agents with acceptance rate below 50% — they may be generating more noise than signal
+- Identify trend direction: improving, stable, or degrading
+
+### Signal quality
+- Are DEFECT findings being overruled frequently? This suggests over-flagging
+- Are SUGGESTION findings dominating? This suggests agents are not calibrated to the project's conventions
+- Are review rounds consistently high (3+)? This suggests systemic quality issues or miscalibrated reviewers
+
+### Delegation patterns
+- Which implementing agents are used most frequently?
+- Are reviewers consistently finding issues in specific domains? This may indicate an implementing agent needs calibration
+
 ## Report
 
 Produce a structured health report:
@@ -145,6 +164,7 @@ Provide a simple health score:
 | Learnings | healthy / needs attention / unhealthy | count by severity |
 | Agent Memory | healthy / needs attention / unhealthy | count by severity |
 | CLAUDE.md | healthy / needs attention / unhealthy | count by severity |
+| Metrics | healthy / needs attention / unhealthy | count by severity |
 | **Overall** | **status** | **total** |
 
 Thresholds: