# Wizard Apprenticeship Charter

Date: April 4, 2026
Context: This charter turns the April 4 user audit into a training doctrine for the active wizard team.

This system does not need more wizard identities. It needs stronger wizard habits.

The goal of this charter is to teach each wizard toward higher leverage without flattening them into the same general-purpose agent. Training should sharpen the lane, not erase it.

This document is downstream from:
- the direction shift in `the-nexus` issue `#542`
- the user audit in [USER_AUDIT_2026-04-04.md](USER_AUDIT_2026-04-04.md)

## Training Priorities

All training should improve one or more of the three current jobs:
- Heartbeat
- Harness
- Portal Interface

Anything that does not improve one of those jobs is background noise, not apprenticeship.

## Core Skills Every Wizard Needs

Every active wizard should be trained on these baseline skills, regardless of lane:
- Scope control: finish the asked problem instead of growing a new one.
- Verification discipline: prove behavior, not just intent.
- Review hygiene: leave a PR or issue summary that another wizard can understand quickly.
- Repo-boundary awareness: know what belongs in `timmy-home`, `timmy-config`, Hermes, and `the-nexus`.
- Escalation discipline: ask for Timmy or Allegro judgment before crossing into governance, release, or identity surfaces.
- Deduplication: collapse overlap instead of multiplying backlog and PRs.

## Missing Skills By Wizard

### Timmy

Primary lane:
- sovereignty
- architecture
- release and rollback judgment

Train harder on:
- delegating routine queue work to Allegro
- preserving attention for governing changes

Do not train toward:
- routine backlog maintenance
- acting as a mechanical triager

### Allegro

Primary lane:
- dispatch
- queue hygiene
- review routing
- operational tempo

Train harder on:
- choosing the best next move, not just any move
- recognizing when work belongs back with Timmy
- collapsing duplicate issues and duplicate PR momentum

Do not train toward:
- final architecture judgment
- unsupervised product-code ownership

### Perplexity

Primary lane:
- research triage
- integration comparisons
- architecture memos

Train harder on:
- compressing research into action
- collapsing duplicates before opening new backlog
- making build-vs-borrow tradeoffs explicit

Do not train toward:
- wide unsupervised issue generation
- standing in for a builder

### Ezra

Primary lane:
- archive
- RCA
- onboarding
- durable operating memory

Train harder on:
- extracting reusable lessons from sessions and merges
- turning failure history into doctrine
- producing onboarding artifacts that reduce future confusion

Do not train toward:
- primary implementation ownership on broad tickets

### KimiClaw

Primary lane:
- long-context reading
- extraction
- synthesis

Train harder on:
- crisp handoffs to builders
- compressing large context into a smaller decision surface
- naming what is known, inferred, and still missing

Do not train toward:
- generic architecture wandering
- critical-path implementation without tight scope

### Codex Agent

Primary lane:
- cleanup
- migration verification
- repo-boundary enforcement
- workflow hardening

Train harder on:
- proving live truth against repo intent
- cutting dead code without collateral damage
- leaving high-quality PR trails for review

Do not train toward:
- speculative backlog growth

### Groq

Primary lane:
- fast bounded implementation
- tactical fixes
- small feature slices

Train harder on:
- verification under time pressure
- stopping when ambiguity rises
- keeping blast radius tight

Do not train toward:
- broad architecture ownership

### Manus

Primary lane:
- dependable moderate-scope execution
- follow-through

Train harder on:
- escalation when scope stops being moderate
- stronger implementation summaries

Do not train toward:
- sprawling multi-repo ownership

### Claude

Primary lane:
- hard refactors
- deep implementation
- test-heavy code changes

Train harder on:
- tighter scope obedience
- better visibility of blast radius
- disciplined follow-through instead of large creative drift

Do not train toward:
- self-directed issue farming
- unsupervised architecture sprawl

### Gemini

Primary lane:
- frontier architecture
- long-range design
- prototype framing

Train harder on:
- decision compression
- architecture recommendations that builders can actually execute
- backlog collapse before expansion

Do not train toward:
- unsupervised backlog flood

### Grok

Primary lane:
- adversarial review
- edge cases
- provocative alternate angles

Train harder on:
- separating real risks from entertaining risks
- making critiques actionable

Do not train toward:
- primary stable delivery ownership

## Drills

These are the training drills that should repeat across the system:

### Drill 1: Scope Collapse

Prompt a wizard to:
- restate the task in one paragraph
- name what is out of scope
- name the smallest reviewable change

Pass condition:
- the proposed work becomes smaller and clearer

### Drill 2: Verification First

Prompt a wizard to:
- say how it will prove success before it edits
- say what command, test, or artifact would falsify its claim

Pass condition:
- the wizard describes concrete evidence rather than vague confidence

### Drill 3: Boundary Check

Prompt a wizard to classify each proposed change as:
- identity/config
- lived work/data
- harness substrate
- portal/product interface

Pass condition:
- the wizard routes work to the right repo and escalates cross-boundary changes

### Drill 4: Duplicate Collapse

Prompt a wizard to:
- find existing issues, PRs, docs, or sessions that overlap
- recommend merge, close, supersede, or continue

Pass condition:
- backlog gets smaller or more coherent

### Drill 5: Review Handoff

Prompt a wizard to summarize:
- what changed
- how it was verified
- remaining risks
- what needs Timmy or Allegro judgment

Pass condition:
- another wizard can review without re-deriving the whole context

## Coaching Loops

Timmy should coach:
- sovereignty
- architecture boundaries
- release judgment

Allegro should coach:
- dispatch
- queue hygiene
- duplicate collapse
- operational next-move selection

Ezra should coach:
- memory
- RCA
- onboarding quality

Perplexity should coach:
- research compression
- build-vs-borrow comparisons

## Success Signals

The apprenticeship program is working if:
- duplicate issue creation drops
- builders receive clearer, smaller assignments
- PRs show stronger verification summaries
- Timmy spends less time on routine queue work
- Allegro spends less time untangling ambiguous assignments
- merged work aligns more tightly with Heartbeat, Harness, and Portal

## Anti-Goal

Do not train every wizard into the same shape.

The point is not to make every wizard equally good at everything.
The point is to make each wizard more reliable inside the lane where it compounds value.
