iopsystems

Use when adding or changing what the rezolus viewer exposes — an /api/v1 endpoint, a dashboard section, the metric catalog, metadata/description derivation, or the frontend data those depend on — or when editing src/viewer/ or crates/viewer/, or reviewing a viewer change. The viewer ships as two separate Rust backends (server + WASM) behind one shared frontend; changing one silently diverges them.

Use when starting or picking up a non-trivial effort (feature, investigation, perf probe, refactor, migration) in a shared repo where teammates or future agents must coordinate or hand off; when a repo has no durable in-tree record of decisions and dead-ends; when you're about to drop a well-measured negative result; or when bootstrapping a journal from a repo's commit history.

Use when reviewing a Rezolus sampler change before merge — a new sampler, a change to an existing sampler's probes/refresh/metrics, or core changes that affect samplers; or whenever a sampler's overhead, cadence, or data source is in question.

Write or update the CLI `--help` text and README section for a new or changed rezolus feature (a subcommand, flag, mode, or behavior change), then prove the help is usable by dispatching a fresh subagent that has never seen the code. Use this whenever you add or change how rezolus is invoked — new `rezolus <subcommand>`, new flags/args on an existing mode, renamed options, or changed defaults — and any time the user says the help/README is thin, stale, confusing, or "an agent couldn't figure this out." Treats help text as an interface under test, not prose.

Tag and push a prerelease from the current Cargo.toml version. Use when the user wants to cut an alpha/beta/rc prerelease. Aborts on stable versions (no `-` in version string) and if the tag already exists.

Create a feature branch, commit changes, push, and open a PR against iopsystems/rezolus

Create a release PR with version bump and changelog update

Run the end-to-end viewer smoke test (`tests/viewer_smoke.sh`). Spawns `rezolus view` in upload-only, file, A/B, and proxy modes, exercises the API endpoints, and verifies experiment attach/detach. Use after any change touching `src/viewer/` or before opening a viewer-related PR.

Use when adding a new model (or model family) to the llm-calc database (src/data/models.ts). Walks through sourcing fields from HuggingFace config.json, reading papers for novel attention variants, writing tests first, and registering the entry. Invoke this whenever a model is being added or updated — even for a single SKU, since the failure modes (wrong KV bytes, mis-sized attention, silently broken roofline) all look fine until someone runs the calc against a real workload.

Use when adding a new accelerator (GPU/TPU/Trainium/Gaudi), interconnect fabric, or multi-accelerator system to the llm-calc database (src/data/{accelerators,interconnects,systems}.ts). Routes to the right sub-procedure based on whether the SKU is a new chip, a new fabric, or a new product composition. Invoke whenever hardware is being added — the failure modes (sparsity-inflated TFLOPS, confused per-direction vs aggregate BW, wrong variant in a system) all produce plausible-looking perf numbers that are silently wrong.

Create a feature branch, commit changes, push, and open a PR against iopsystems/llm-calc

Use when starting or picking up a non-trivial effort (feature, investigation, perf probe, refactor, migration) in a shared repo where teammates or future agents must coordinate or hand off; when a repo has no durable in-tree record of decisions and dead-ends; when you're about to drop a well-measured negative result; or when bootstrapping a journal from a repo's commit history.

Create a feature branch, commit changes, push, and open a PR against iopsystems/metriken

Release a single metriken workspace crate — bump its version, update the changelog, tag, and (gated) publish to crates.io

When making code changes or reviewing existing code, check if architecture diagram matches implementation, and keep the diagram in sync.

Prepare outstanding commits on a feature branch for a pull request to upstream

Create a feature branch, commit changes, push, and open a PR against iopsystems/llm-perf

Create a release PR with version bump and changelog update

Formats the codebase using nightly rustfmt. Use when asked to "format the code", "run rustfmt", "cargo fmt", or when formatting is needed after code changes.

Create a release PR with version bump, then auto-tag after merge