timmy-home/docs/WIZARD_APPRENTICESHIP_CHARTER.md

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

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.