dev-testing-python
Skill179 starsChanged 12 days agoApache-2.0View on GitHub
Python test infrastructure for capsem-builder. Use when running Python tests, checking coverage, or working with golden fixtures and generated schemas.
In this repository37 other files it gives its agents.
- AGENTS.mdAGENTS.md
- asset-pipelineSkill
- build-imagesSkill
- build-initrdSkill
- citadelSkill
- dev-benchmarkSkill
- dev-bug-reviewSkill
- dev-cacheSkill
- dev-capsem-doctorSkill
- dev-capsemSkill
- dev-ciSkill
- dev-debuggingSkill
- dev-gateSkill
- dev-installationSkill
- dev-justSkill
- dev-mcpSkill
- dev-mitm-proxySkill
- dev-rust-patternsSkill
- dev-session-debugSkill
- dev-setupSkill
- dev-skillsSkill
- dev-sprintSkill
- dev-startSkill
- dev-testing-frontendSkill
- dev-testing-hypervisorSkill
- dev-testingSkill
- dev-testing-vmSkill
- frontend-designSkill
- ironbankSkill
- meta-find-skillsSkill
- meta-organize-skillsSkill
- meta-skill-creationSkill
- release-processSkill
- site-architectureSkill
- site-infraSkill
- site-marketingSkill
- use-capsemSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 27
Import: direct build_system/builder/ mapping to capsem_builder
- Distinctive: line 69
If you change the settings schema (node types, metadata fields), all three must be updated together.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Python Testing (capsem-builder)
Quick reference
python3 build_system/scripts/ci/run-bounded-command.py --timeout-seconds 120 -- \
uv run --project build_system --frozen python -m pytest \
-c build_system/pyproject.toml --rootdir . build_system/tests/image/ --no-cov
python3 build_system/scripts/ci/run-bounded-command.py --timeout-seconds 60 -- \
uv run --project build_system --frozen python -m pytest \
-c build_system/pyproject.toml --rootdir . \
build_system/tests/image/test_validate.py -k E001 --no-cov
just test <source-commit> # Complete qualification, governed by AGENTS.mdPackage config
build_system/pyproject.toml:
- Distribution:
capsem-builder - Import: direct
build_system/builder/mapping tocapsem_builder - Entry point:
capsem-builder = capsem_builder.gatelaunch:builder_main, which selects the project interpreter before dispatching to the image CLI - Build: setuptools, with no nested
src/or compatibility package tree - Tests:
build_system/tests/, using the lockedbuild_system/uv.lock
The gate already lives in build_system/builder/gate/. The installed package
mapping and pytest's configured search paths own imports; do not add an obsolete
source root to PYTHONPATH. Explicit -c and --rootdir keep mixed image,
gate and cross-system tests under the same configuration and import namespace.
Test directory: build_system/tests/image/
| File | What it covers |
test_validate.py | TOML config linting, error codes E001-E305, warnings W001-W012 |
test_models.py | Pydantic image and image-workspace models |
test_cli.py | Backend-only Click CLI surface |
test_docker.py | Jinja rendering and image-build execution primitives |
test_manifest.py | BOM collection, manifest rendering, package parsers |
test_config.py | TOML loading, defaults generation, roundtrip |
test_doctor.py | Build prerequisite and source-completeness checks |
test_audit.py | Trivy/grype parsing and severity summaries |
test_image_build_backend.py | Private capsem-admin backend command |
test_image_module_boundary.py | Exact source, package, and entrypoint ownership |
Coverage
- Floors, combined coverage and report locations belong to
config/gate.tomland the owning gate steps. A focused--no-covrun is diagnostic feedback. codecov.yml: builder component includesbuild_system/builder/**
Golden fixtures and cross-language conformance
Golden fixture at tests/settings_spec/golden.json with expected output at tests/settings_spec/expected.json. Three language parsers must produce identical results:
| Language | Test file |
| Python | tests/test_settings_spec.py |
| Rust | crates/capsem-core/tests/settings_spec.rs |
| TypeScript | web/app/src/lib/__tests__/settings_spec.test.ts |
If you change the settings schema (node types, metadata fields), all three must be updated together.
Schema generation pipeline
config/settings/settings.toml -> Pydantic models -> config/settings/schema.generated.json (JSON Schema)
-> config/settings/ui-metadata.generated.json (UI metadata)just _generate-settingsruns the settings-generation owner. Wrap this direct development command with the bounded runner specified in AGENTS.md.- Rust reads
config/settings/ui-metadata.generated.jsonviainclude_str!()inregistry.rs - TypeScript validates against
config/settings/schema.generated.jsonin conformance tests
In-VM tests (NOT pytest on host)
guest/artifacts/diagnostics/ contains the pytest tests that run INSIDE the VM via just exec "capsem-doctor". These are NOT part of the host uv run --project build_system --frozen pytest suite. They test the guest environment (mounts, networking, sandbox, MCP, runtimes). See /dev-testing-vm for details.
Source layout
build_system/
pyproject.toml
uv.lock
builder/ # installs as capsem_builder
image/
__init__.py
cli.py Backend-only Click CLI entry point
config.py TOML config loading, defaults generation
models.py Pydantic models (GuestImageConfig, ArchConfig, etc.)
schema.py Settings schema (SettingsRoot, GroupNode, SettingNode)
docker.py Jinja Dockerfile rendering, Docker build execution
manifest.py BOM collection, manifest rendering
validate.py Compiler-style linting with error codes
audit.py Trivy/grype output parsing
image_build_backend.py Private capsem-admin image build backend
doctor.py Build environment doctor checks
tests/
image/Runtime image templates remain under config/docker/; they are not
Python package data and do not move into build_system/.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

