CKS_FINALE

NOTES.md

@@ -0,0 +1,42 @@
+# 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.