titan-iac/services/hermes/skills/master-hermes-on-atlas/references/curriculum.md

# Hands-on curriculum

Complete labs by evidence, not elapsed time. A focused pass can establish
operational competence in several days; mastery requires repeating real triage
and recovery work over multiple incidents.

Run the curriculum on `openai-codex/gpt-5.6-terra`. Use the local model only for a
deliberate comparison lab; it is not the default coach for multi-reference work.

## Phase 1: orientation and control

### Lab 1 — Map the system

From the web UI, identify Chat, Sessions, Files, Models, Logs, Cron, Skills,
Plugins, MCP, Channels, Webhooks, Pairing, Profiles, Config, Keys, System, and
Documentation. Explain which state belongs to the operator PVC and which
components are shared. Verify three claims with read-only CLI output.

Success evidence: a correct diagram or written request path from browser to
agent to model, including the fallback branch and the consumer boundary.

### Lab 2 — Models, context, and fallback

Inspect `hermes status`, `hermes fallback list`, deployment placement, and GPU
owner state. Explain why a 32K model was rejected, why normal Codex-backed chat
remains available when Wolf owns the GPU, and when the local fallback can run.

Success evidence: predict outcomes for local healthy, local slow, gate 503,
invalid local response, and expired Codex authorization without changing state.

### Lab 3 — Sessions, files, profiles, and logs

Create a named training session and a harmless workspace note through the UI,
then find the corresponding session/file/log surfaces. Inspect profile and
backup help without creating a profile or backup.

Success evidence: explain persistence, what survives a pod replacement, what is
instance-local, and how to recover a lost conversation without exposing auth.

## Phase 2: tools and safe autonomy

### Lab 4 — Tools versus skills versus MCP

Use `hermes tools`, `hermes skills`, `hermes plugins`, and `hermes mcp` help or
list/status views. Classify each as executable capability, procedure/context,
packaged extension, or external protocol integration. Explain why a skill is
not a security boundary.

Success evidence: choose the right mechanism for three examples: repeatable
Titan triage, a read-only external API, and a scheduled notification.

### Lab 5 — Prove the permission boundary

Use `kubectl auth can-i` as both service accounts. Inspect the relevant
ClusterRoles and NetworkPolicies. Do not attempt mutations.

Success evidence: an allow/deny matrix covering pods, logs, Secrets, exec,
deployment patch, Flux reads, Flux reconcile, the model gate, internal services,
and public web research.

### Lab 6 — Channels, pairing, webhooks, and cron

Inspect the configured state and help for gateway/channels, pairing, webhooks,
and cron. Design one safe notification workflow and one unsafe workflow. Do not
register a channel, create a webhook, or schedule a job during the lab.

Success evidence: identify the identity, secret, audience, tool policy, failure
mode, audit trail, and revocation path for the proposed integration.

## Phase 3: the interview workflow

### Lab 7 — Deterministic live triage

Invoke `$triage-titan-test-failures`. Read the current Ariadne diagnosis and
bundle, then correlate one suite with Jenkins, Flux/Git, cluster health, and
quality metrics. Keep every collection step read-only.

Success evidence: the required structured triage result with timestamps and no
invented evidence.

### Lab 8 — Incident simulations

Use one student packet from `incident-drills.md`. Diagnose it before receiving
coach notes. Repeat until three cases score at least `Independent`.

Success evidence: correct failure class, causal chain, next checks, minimal
repo-side correction, and explicit approval boundary.

### Lab 9 — Build and evaluate a reusable skill

Identify a stable repeated workflow, create a small skill in the operator's
writable skills directory, inspect it, and test it against a fresh incident.
Do not alter the Flux-mounted training or triage skills.

Success evidence: precise trigger description, concise procedure, progressive
disclosure where useful, one passing case, one adversarial case, and a stated
permission boundary.

### Lab 10 — Model outage drill

Use retained logs/current status or a separately approved maintenance window.
Do not take the live model down for training. Explain the expected trace from
model gate to fallback, recognize an auth failure, and name the restoration
checks.

Success evidence: correctly distinguish model unavailability, context rejection,
provider auth failure, and agent failure.

## Phase 4: independent operation

### Lab 11 — Supervised real incident

Lead a real failure triage from intake to an approved repo-side proposal. A
human applies any change through Git/Flux. Verify the result read-only.

### Lab 12 — Teach it back and audit the claims

Explain the complete architecture and demonstrate the workflow without hints.
Audit each sentence of the interview answer using the claim table in
`mastery-rubric.md`. Weaken or qualify anything not supported by evidence.

## Suggested pace

- Day 1: Labs 1–3.
- Days 2–3: Labs 4–6.
- Days 4–7: Labs 7–10.
- Weeks 2–4: repeat Labs 7–11 on real incidents; improve one skill from observed
  failures; finish with Lab 12.

Do not advance solely because a day elapsed. Re-run any lab graded below
`Independent`.