# Teaching notes

- Prefer practical, scenario-based tasks that are harder than the real CKS exam.
- Present exactly one active question in `ANSWER.md`.
- Make answering easy with explicit headings, checkboxes, and fenced blocks.
- Do not reveal or implement the solution to an active question.
- Review only what the learner wrote in `ANSWER.md`.
- On an imperfect submission, create a checklist of observed mistakes, but expose and coach only one mistake at a time.
- Hint ladder: (1) goal-oriented nudge, (2) concept pointer, (3) narrow official-doc reference, (4) command/API-shape clue, (5) near-complete scaffold with blanks. Never fill the final answer.
- Score after the submitted answer is functionally complete, then require a fresh transfer question before declaring the topic satisfactory if any coaching was needed.
- One-attempt success on a fresh question means satisfactory; otherwise continue the same topic with a new question after remediation.
- Interleave older mastered skills into later questions for retention.
- Keep questions compact: one focused operation, minimal prose, and a short Section B answer area.
- For configuration-edit tasks, provide the complete realistic exercise file (or a clearly labeled complete exam-supplied file), not only the line to change. The learner should practice locating the field and preserving structure/indentation.

## Mastery and scoring protocol

1. Learner edits `ANSWER.md` and says the attempt is ready.
2. Teacher evaluates the answer against an unpublished functional rubric.
3. If incomplete, teacher records all detected issues internally but presents only the first unresolved mistake.
4. Learner fixes that mistake in the file. Teacher then verifies it and reveals the next mistake, if any.
5. Only Section B (the implementation/manifests) is scored, out of 100:
   - Functional correctness against the requested end state: 70
   - Security and least privilege: 20
   - Manifest/API precision: 10
   Sections A, C, and D are checked for correctness and used for feedback, but contribute zero points.
6. If the original attempt earned at least 90 and required no correction, mark the topic satisfactory.
7. If correction or hints were needed, give a new, harder transfer question in the same topic. Only a first-attempt score of at least 90 with no critical security error unlocks the next topic.
8. Attempts are counted per question; topic status is tracked in `CKS-SYLLABUS-CHECKLIST.md`.

## Gamification

- Clean first-attempt completion: 100 XP.
- Completion after remediation: 40 XP.
- Topic mastery bonus: 150 XP.
- Skipped question: 0 XP.
- Ranks: Cadet (0), Scout (100), Defender (250), Sentinel (500), Guardian (900), CKS Elite (1400).
- Keep `dashboard.html` synchronized whenever a question is graded, completed, skipped, or unlocked.
- Ignore harmless spelling/formatting slips when intent and executability remain unambiguous. Still flag errors that break a command, invalidate YAML, change security behavior, or omit a required outcome.
- Learner reports strong confidence with Ingress and TLS but frequently forgets or mistypes NGINX Ingress annotations; interleave annotation recall later.
- Never skip, archive as incomplete, or advance past an active question unless the learner explicitly uses the word `skip` or clearly says to move to the next topic. Treat `go`, `check`, `verify`, and similar short messages as requests to continue checking the current answer.
- Keep tasks close to realistic CKS execution complexity. Do not require defensive shell control flow (`if`, elaborate `&&` chains, scripting) when a candidate can run a verification command, observe its result, and then perform the next command. Hardness should come from Kubernetes security judgment, not incidental shell puzzles.