Skip to main content

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-mounts drills/ and exams/, so a staged file is visible to the server as soon as it is written. The team never rebuilds or stops kubiq.
  • kubectl on 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)

Source distribution for swarmr-kubiq 0.3.0
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)

Table of built distributions (wheels) for swarmr-kubiq 0.3.0
File Interpreter ABI Platform Actions
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.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page