296 lines
6.8 KiB
Markdown
296 lines
6.8 KiB
Markdown
|
|
# 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.
|