Proposal: Kubernetes hands-on drills as a Web UI mode (kdrill) #53

Activity

1. NetDevAutomate commented on Oct 4, 2026

   

   NetDevAutomate

   on Oct 4, 2026

   Owner

   More actions

   Hi Bruno,

   Many thanks for opening this before writing code, and for the detail.

   I would love to introduce a module capability to facilitate a standardised community module index with hands on tech specific labs.

   StudyLoop was created for the community and my sincere hope is to get the wider community involved to make this a much better community based tool.

   I'm looking into how to add to the repo and to https://www.studyloop.dev/ a more comprehensive contributing section.

   Short version: no objection; kdrill is the first module I want StudyLoop to carry, and I'd like to use it to set the standard every later module follows, so that contributing a topic never requires reviewing core.

   What I did with your proposal
   Rather than answer the three questions in isolation I wrote up a module contract — how any technology-specific drill set plugs into StudyLoop — and had it reviewed by a four-model council before replying (the arbitration sits next to it). It is written for you and has eleven questions, each with a recommended answer, so "yes" or "no, because …" is a complete reply:

   Proposal

   • https://github.com/NetDevAutomate/StudyLoop/blob/main/openspec/changes/module-contract-v1/proposal.md

   Implementation plan

   • design.md and tasks.md in the same folder.
   • One paragraph: a module is a directory of data - module.yaml, drills in StudyLoop's existing PracticeDeck JSON, a mentor/brief.md, your scripts/ — that core validates, lists under one generic Labs entry, and runs through its own runner, consent and mentor.
     • Modules declare; core executes.
     • Nothing a module ships is imported by core.

   Your three questions

   • Menu mode? Neither a Kubernetes mode nor "under practice tasks": one generic Labs entry, hidden until a module is installed, listing drills by module. Otherwise every technology becomes a menu item. The entry is StudyLoop's; the content is yours.

   • Auto Coach and per-deck trust for read-only checks? Not as a YAML label — "read-only" has to be a capability the runner enforces, not something a deck declares. In v1 every phase (setup / check / cleanup) is consented per execution: the exact argv and the content digest of your script are shown, confirmed, and re-checked at spawn (R-15 extended from the command text to the script). The learner triggers each check explicitly and the result goes to the Socratic mentor, which decides what to say. There is no automatic check after each command in v1. The standing grant Auto Coach needs is v2, together with a view-only credential (an RBAC view ServiceAccount in the injected kubeconfig) that makes it defensible — §5.5 says why they ship together. Expectation-setting: in the MVP the check runs from the CLI (studyloop drill check //) while the drill itself runs in the web terminal; the browser Check progress button is v1.1 because it is a new HTTP consent surface.

   • kind + Docker as an optional extra with doctor checks? Yes. Prerequisites are an enum core owns (docker, kind, kubectl in v1); the probes live in core's doctor/, report only for installed modules, and never create a cluster or switch context. Default tests run with nothing installed; live drills sit behind STUDYLOOP_LIVE=1 (the TF_ACC=1 pattern).

   • Your mapping was right on all three seams — decks with verification.kind: command plus setupCommand, the existing live console, the mentor as the coaching voice.

   What is live for you as of this comment

   • The schema half merged in : PracticeDeck now accepts the six additive fields from §5.3 — id on the deck and on each task, solution, scaffolding (guided / hinted / unaided / exam, your L0–L3), mentorNotes, and verification.cleanupCommand. Until studyloop module check lands (the next lane), validate converted decks from your StudyLoop checkout with:

   uv run python -c 'import sys, pathlib; from studyloop.learning.practice import load_practice_deck; [print(p, "ok:", len(load_practice_deck(pathlib.Path(p)).tasks), "tasks") for p in sys.argv[1:]]' decks/*.json

   • That is the same Pydantic model MC004 will use, extra: forbid included, and it records nothing. The manifest (module.yaml, §5.2) can only be drafted against the proposal for now. Order from here: module check / module add, then the runner and studyloop drill, then the Labs entry; your live proof against a disposable kind cluster (DoD item 7) is the acceptance test of the whole standard — if kdrill needs something the contract lacks, either the need is generic and v1 grows, or kdrill adapts.

   The plan, slightly redirected

   • Install it and use it as a learner first - yes please, and tell me what is wrong.
   • Then: the module lives in your own repository, not on a fork branch — studyloop-module-kubernetes-drills, GitHub topic studyloop-module (the terraform-provider- convention; kdrill can stay the nickname).
   • PRs to core are for gaps in the contract - a prerequisite id, a target kind, a conformance rule - and those should be small, exactly as you planned.
   • Your fork is the right place for those.

   Things I would rather you avoid

   • Teaching core a second drill format: convert kdrill's YAML to PracticeDeck (Q1 — what does not map?).
   • Shell strings in checks: each phase is one executable under scripts/ plus literal arguments, run as argv with no shell; exit 0 passed, 1 task not complete, ≥2 could not run (Q3 — do your checks fit, or need a thin wrapper?).
   • --context, --kubeconfig or use-context in commands: the runner injects a kubeconfig holding exactly one context, a disposable per-attempt cluster that core creates.
   • Any learner-facing hint or solution surface: hint, solution and the brief reach the learner only through the mentor. Checks and facts from the module; teaching from the mentor.
   • Inferring command completion from prompt text, or anything that runs without consent.
   • Two things only you can answer: does any CKA/CKAD/CKS check genuinely need to read Secrets (Q4 — it shapes v2's credential, not v1), and are you happy to rename the repo when you start the conversion (Q9)? Reply to the eleven questions - "yes" to most is fine - and I will adjust the proposal and put dates on the next lanes.
2. NetDevAutomate

   added 7 commits that reference this issue on Oct 12, 2026

   docs(openspec): propose module contract v1 for discussion

   ...

   75bab23

   docs(openspec): draft the #53 reply, to post at the schema-lane merge

   ...

   3e271af

   docs(openspec): S-merge task posts the drafted #53 reply

   ...

   eb75d6d

   docs(openspec): wave-0 setup — lane briefs, review cadence, catch-rat…

   ...

   f8c6866

   docs(openspec): autonomous-run mandate and the lane-merge review brief

   ...

   fa76824

   docs(openspec): S lane closed — catch-rate row, tasks ticked, #53 dra…

   ...

   1e4a777

   docs(openspec): M2 arbitration — release-ready pending owner steps; t…

   ...

   523ac28