swarmr-kubiq
Exam authoring team for swarmr. Writes a Kubernetes mock exam for kubiq, the drill files and the exam manifest, and proves every question on a live kubiq session before the files are handed to you for review.
Mutating by design, in two places only: the kubiq checkout, under the exam's own paths, and the running kubiq, through sessions the team itself opens and a catalogue reload. Git is never run: you review and commit. Nothing about the catalogue is hardcoded: the team profiles the checkout at startup and injects what it found into every prompt.
Install
Core and this team must land in the same environment.
uv tool install swarmr --with swarmr-kubiq
That exposes teams and teams-mcp on your PATH; this team ships no command of
its own. From a checkout: uv tool install ../swarmr --with ../swarmr-kubiq.
teams --target exam_author --exam ckad-mock-7
teams exam_author --exam ckad-mock-7 --version 1.35 "create a new CKAD mock exam"
Over MCP the tool is
start_exam_author(request, exam, kubiq?, certification?, server?, version?, questions?).
The proof
The team does not trust a question it has not run. Every drill is staged into the checkout, kubiq reloads it, and the harness opens a session on the real cluster: it grades the untouched namespace (every check must fail), runs the drill's own solution in the candidate's shell, grades again (every check must pass, inside the solve budget), ends the session and verifies the cluster is back to baseline. Only a question that survives all of that is proven.
A critic then tries to refute each proven question from its record alone: the
task against the checks, the cited documentation, the curriculum. It rules
confirmed, refuted or unproven. Only confirmed is filed. Proofs and
rulings are kept under ~/.cache/swarmr-kubiq/, keyed by the drill's content,
so a rerun proves and judges only what changed; a rerun on an unchanged exam is
a report and nothing else.
What a model cannot be trusted to get right, a tool refuses: weights that do not mirror the curriculum shares, a namespace another exam uses, a drill that is a rewording of one in the catalogue or of a sibling, a kind the cluster does not serve, a check that can never pass, a solution that changes nothing, a private key, a changed task on a fix round. The author fixes what the tool names.
Prerequisites
- A running kubiq built from a checkout with
POST /api/reload, whose compose file bind-mountsdrills/andexams/, so a staged file is visible to the server as soon as it is written. The team never rebuilds or stops kubiq. kubectlon PATH, pointed at the cluster kubiq provisions sessions on.lodestar(MCP) for the Kubernetes documentation; unreachable degrades to empty searches, never to a failure.
Arguments
Per call, as --flags on the CLI or arguments of the MCP tool. Nothing about
the target comes from the environment except the checkout, which defaults to
the current directory.
exam is required: the id to author, which must not exist yet. kubiq is the
checkout root holding drills/ and exams/. certification is CKAD
(default), CKA or CKS. server is the running kubiq, default
http://localhost:8080. version is the Kubernetes minor to author against,
refused above the cluster's. questions is the count, default 21 (19 for CKS);
a count whose weights cannot mirror the curriculum shares is refused.
Tuning: KUBECONFIG (the cluster), KUBIQ_SOLVE_BUDGET (seconds a solution
plus convergence may take, default 120), KUBIQ_SETTLE_SECONDS (grader
convergence cap, default 90), XDG_CACHE_HOME (where proofs live),
LODESTAR_COMMAND / LODESTAR_URL. Model credentials come from swarmr
(KIMI_*).
A session the team did not open is never touched: a reload or a proof is refused
while one exists. The report names the files and the git and gh commands to
open the PR; it runs neither.
References
Metadata
Release files for swarmr-kubiq 0.3.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| swarmr_kubiq-0.3.0.tar.gz | 113.7 kB | Without provenance | Details for swarmr_kubiq-0.3.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| swarmr_kubiq-0.3.0-py3-none-any.whl | Python 3 | none | any | Details for swarmr_kubiq-0.3.0-py3-none-any.whl |
Total release size: 192.7 kB
Release files / swarmr_kubiq-0.3.0.tar.gz
| Download URL | swarmr_kubiq-0.3.0.tar.gz |
|---|---|
| Size | 113.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
9e980cd30723917546c87a2252942e3f7bd6881b03a1f1870b4f747373d57250
|
|
BLAKE2b-256 checksum How to use checksums |
c26b79549fd4348fbc8a44aecaf81f1fe68fdafa8620eacd25ebcf7216435477
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
uv/0.13.5 {"installer":{"name":"uv","version":"0.13.5","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Release files / swarmr_kubiq-0.3.0-py3-none-any.whl
| Download URL | swarmr_kubiq-0.3.0-py3-none-any.whl |
|---|---|
| Size | 79.0 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
32d922d45b6b609629b4ed25e9a84759bc4fc29a093f52b4be900047a830cec0
|
|
BLAKE2b-256 checksum How to use checksums |
a4bad9c0990c24c345e65574f673b9644b9612d185d97bf300a8423560455663
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
uv/0.13.5 {"installer":{"name":"uv","version":"0.13.5","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Security for swarmr-kubiq 0.3.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.