Review process

Eelden’s architect reviews agent-written code but does not write Rust day-to-day. Reviews teach while they ship. Full rules: AGENTS.md.

When a review guide is required

Add internals/review-guides/<topic>.md for a substantial PR: new module, new concept, or anything touching concurrency or byte-level layout.

Template: async-pager.md.

Every guide must cover:

1. The gnarliest lines and why they are shaped that way
2. What could hide a bug from a Rust-newcomer reviewer
3. Which tripwire tests protect which invariant

Reviewer questions

Every review guide ends with 3–5 questions the reviewer should answer before approving, with answers after a divider at the bottom.

Questions test judgment (“what breaks if this brace moves?”), not trivia.

Rust notes

When a change introduces a Rust concept not yet covered in internals/rust-notes/, add a chapter — using Eelden’s real code as the example, never toy code. One concept per chapter; same reviewer-questions format as review guides.

PR description duties

Explain in the PR description:

• Every unsafe block (should be rare; usually forbidden)
• Every non-elided lifetime
• Every layer of locking or shared ownership (Mutex, Arc, Rc)
• Every new dependency (must also land in internals/decisions.md)

Reviewer checklist (short)

• [ ] Clippy/fmt/tests green; wasm builds if touched
• [ ] Status / consumer docs updated if capabilities changed
• [ ] Review guide present when the change is substantial
• [ ] Tripwires cover the invariants the type system is supposed to hold
• [ ] Naming matches NAMING.md