crate-ops

Crate Ops

Any harness (Muse, Claude Code, Codex, VT Code, human) can run this workflow. It is the procedure, not the runner: a Muse executable version lives at .agents/workflows/crate-ops.js, but the steps below are the source of truth.

The core trap: feature-unification masking

A workspace-wide build (cargo check, ./scripts/check-dev.sh) unifies features across all default members. A crate can compile there while its own manifest is broken: a missing features = ["..."] declaration only surfaces when the crate builds alone (cargo check -p <crate>), in a restricted CI command, or during cargo publish verification (which rebuilds the packaged tarball). Real case: vtcode depended on vtcode-core with default-features = false and no explicit tui, so the binary failed with 145 errors everywhere except the default workspace build.

Workflow

1. Orient

• Read root AGENTS.md and each touched crate's AGENTS.md.
• Read the touched manifests plus every dependent's declaration of the changed crate (grep -rn '<crate-name>' --include=Cargo.toml crates/ Cargo.toml, excluding target/).
• Check git log on the manifests for intent behind default-features = false or version pins.

2. Reproduce in isolation

Reproduce with the crate alone, never with a workspace-wide build:

cargo check --locked -p <crate>

Match the failure against the reported one (same crate, same error class/count) before changing anything.

3. Fix

• Keep changes surgical: only touch files the change owns.
• When a crate needs an optional feature of a dependency, declare it explicitly on that dependency edge. Precedent (fuzz/Cargo.toml, root Cargo.toml): vtcode-core = { path = "...", version = "...", default-features = false, features = ["tui"] }
• Keep path+version on all workspace path dependencies; never rely on unification from other members.
• Follow repo rules: anyhow::Result with context, no unwrap/expect/panic in production code, workspace lints apply. Do not commit unless asked.