The codeArbiter Learning Path

You do not need to understand codeArbiter’s internals before using it. Follow this path in order, perform the short exercise in each stage, and keep the proof it asks you to produce. The reference stays available for lookup; the path teaches you when and why to use it.

1 Foundation2 Daily operation3 Governed autonomy4 Power user

Stage 1: Foundation

Target: a verified install

Know what is enforcing your repository.

Choose one host, install its adapter, opt a disposable repository in, and prove the blocking hook actually runs. This is the minimum trustworthy starting point.

1. Understand the promise and request flow5 min
2. Choose Claude Code, Codex, or Pi5 min
3. Install and trust the adapter10 min
4. Protect a disposable repository15 min

Proof Doctor reports a healthy H-03 live-fire probe, and $ca-status or its host-native equivalent names your branch, stage, tasks, and questions.

Stage 2: Daily operation

Target: choose the right lane

Turn ordinary development work into repeatable evidence.

Learn the difference between new behavior, a known defect, investigation, dependency risk, and an architectural decision. The power move is choosing the smallest correct lane before work begins.

1. Learn the gated-lane model8 min
2. Build a feature end to end15 min
3. Fix a confirmed defect test-first5 min
4. Add a dependency safely10 min
5. Record an architecture decision10 min
6. Use an override without hiding it5 min

Proof Given a feature, a failing behavior with unknown cause, and a known regression, you can explain why they route to feature, debug, and fix respectively.

Stage 3: Governed autonomy

Target: delegate without losing control

Approve the destination, then audit the decisions.

An autonomous sprint is not a longer prompt. It has one interactive spec-and-plan gate, persisted tasks, SMARTS-scored non-hard decisions, hard stops, exact-head review, and a PR boundary.

1. Run a resumable sprint15 min
2. Read and challenge SMARTS verdicts8 min
3. Use checkpoints for periodic review8 min
4. Detect context drift8 min
5. Assemble the audit story8 min

Proof You can locate the approved spec, execution plan, task board, sprint decision log, low-confidence calls, and exact PR head without relying on chat history.

Stage 4: Power user

Target: diagnose and extend

Operate the system from source-backed evidence.

Power users do not memorize every hook or environment variable. They know where state lives, how to trace a verdict to source, how to recover a stale install, and which changes require a specialist lane.

1. Read the repository-owned state store10 min
2. Configure scope and runtime behaviorLookup
3. Trace a hook from event to verdict10 min
4. Understand blocking and fail-loud behavior10 min
5. Diagnose installation and runtime failures10 min
6. Cut a target-aware release10 min
7. Evaluate previews without confusing them with stable features5 min

Proof Starting from a hook ID, you can find its event, blocking behavior, implementation source, relevant configuration, remediation path, and durable audit record.

Power-user capstone

Use a disposable repository. Do not perform this exercise in active production work.

Final exercise

Prove the entire operating loop.

1. Run doctor and save the live-fire result.
2. Use status to identify the stage, current branch, one task, and one open question.
3. Explain which lane owns a new feature, a confirmed bug, a risky dependency, and a structural refactor.
4. Locate the hook-gate entry for H-03 and the source file that emitted your block.
5. Find the security controls and commit-gate references that govern migration, CI, and deployment scope.
6. Describe what an override records and what authority it does not grant.
7. Trace one sprint decision from the log to its SMARTS evidence and confidence flag.
8. Explain why a green local test is not proof that a pull request is safe to merge.

You are a codeArbiter power user when you can complete all eight from the repository and docs without reconstructing the answer from a prior chat.

Keep this path honest

The docs intentionally separate three kinds of evidence:

• Captured product evidence comes from a real shipped path and includes its source digest.
• Generated reference comes from current plugin frontmatter and source files on every build.
• Conceptual diagrams explain relationships; they are not presented as runtime captures.

When those disagree, trust the live source and file an issue. The site should make the discrepancy obvious, never smooth it over.