code-craft

Code craft

Prove what the types can, then test only what they cannot. Every invariant has one owner: the strongest rung of the proof ladder that can actually prove it. In order: types and linters, effects, proofs, database constraints, unit tests, integration tests, end-to-end tests.

Use the repository's current instructions and established conventions. Apply these defaults where the requested change needs a design decision; they do not authorize unrelated restructuring or new tooling.

Read the reference for the decision in scope:

Decision	Reference
Decide which rung owns an invariant	Proof ladder
Represent states, workflows, and domain identities	Illegal states
Decode external input into useful types	Parse, don't validate
Type dependencies, failures, and resource lifetimes	Effects
Model recoverable errors and required gates	Errors as values
Guard a sensitive precondition	Proof parameters
Choose an abstraction or investigate performance	Simplicity
Maintain module boundaries and their documentation	Architecture docs

Read a language reference only when its idioms, concurrency, or tooling details matter: TypeScript, Rust, Go, or Python.

For new TypeScript code and the full project template, Jess's stack is Effect, Effect Schema or Zod, xstate, and gdp-ts. For new Rust servers it is tokio, axum, snafu, aerosol, and sqlx. In an existing repository, use its equivalents; adding any of these is an architecture change to ask about first.

Use database-craft for schemas, constraints, queries, and jobs, and testing-craft for the test rungs. Repository setup belongs to project-bootstrap when that setup is requested. Follow the project's required verification; reviews do not automatically require a full test suite.

Adapted from leonardomso/rust-skills (MIT), Matklad's Rust100k series, Alexis King's writing on parsing and type safety, and Matt Noonan's Ghosts of Departed Proofs.