Add wizard apprenticeship charter #398
295
docs/WIZARD_APPRENTICESHIP_CHARTER.md
Normal file
295
docs/WIZARD_APPRENTICESHIP_CHARTER.md
Normal file
@@ -0,0 +1,295 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user