poly-and-release-workflow

# Poly + Release Workflow The canonical order to run before pushing a change. Each step gates the next; do not skip. ## Local check loop ```bash cargo fmt cargo clippy --workspace --all-targets --tests -- -D warnings cargo test --workspace poly lint . ``` Why this order: - `cargo fmt` first so clippy / poly don't fail on formatting. - Clippy strict (`-D warnings`) — surface real issues before the broader poly sweep. - Unit + integration tests catch logic regressions before the slow harness. - `poly lint .` is the meta-linter: typos, markdownlint (120-char cap), cargo-deny licenses, cargo-machete unused deps, rustdoc-lint, rust-max-lines (1000-line cap on `src/**/*.rs`). ## Harden harness After the local loop passes: ```bash BASEMIND_HARDEN_NO_BUILD=1 \ cargo test --release --test harden -- --ignored --nocapture \ 2>&1 | tee /tmp/basemind-harden-$(date +%s).log ``` - `BASEMIND_HARDEN_NO_BUILD=1` reuses `target/release/basemind` — saves ~30s per run. Drop it when you're suspicious the binary is stale. - Expect 8/8 green: ripgrep, tokio, typescript, react, django, requests, gin, ripgrep-shallow. - Canaries: tokio `spawn_hits >= 200`, django `get_hits >= 200`, react `useState_hits >= 20`, ripgrep-shallow `any_truncated == true`. ## Commit + push - Conventional Commit prefix (`feat:`, `fix:`, `perf:`, `chore:`, `refactor:`). - Body explains *why*. Mention schema bumps (`INDEX_SCHEMA_VER` / blob format) and added dependencies. - Co-author trailer per repo convention....