# Hisab — Claude Code Instructions
## Project Identity
**Hisab** (Arabic: calculation/mathematics) — Higher math — linear algebra, geometry, calculus, numerical methods, spatial structures
- **Type**: Flat library crate
- **License**: GPL-3.0
- **MSRV**: 1.89
- **Version**: SemVer 0.D.M pre-1.0
## Consumers
impetus (physics), kiran (engine), joshua (simulation), aethersafha (compositor)
## Development Process
### P(-1): Scaffold Hardening (before any new features)
0. Read roadmap, CHANGELOG, and open issues — know what was intended before auditing what was built
1. Test + benchmark sweep of existing code
2. Cleanliness check: `cargo fmt --check`, `cargo clippy --all-features --all-targets -- -D warnings`, `cargo audit`, `cargo deny check`, `RUSTDOCFLAGS="-D warnings" cargo doc --all-features --no-deps`
3. Get baseline benchmarks (`./scripts/bench-history.sh`)
4. Internal deep review — gaps, optimizations, security, logging/errors, docs
5. External research — domain completeness, missing capabilities, best practices, world-class accuracy
6. Cleanliness check — must be clean after review
7. Additional tests/benchmarks from findings
8. Post-review benchmarks — prove the wins
9. Repeat if heavy
### Work Loop / Working Loop (continuous)
1. Work phase — new features, roadmap items, bug fixes
2. Cleanliness check: `cargo fmt --check`, `cargo clippy --all-features --all-targets -- -D warnings`, `cargo audit`, `cargo deny check`, `RUSTDOCFLAGS="-D warnings" cargo doc --all-features --no-deps`
3. Test + benchmark additions for new code
4. Run benchmarks (`./scripts/bench-history.sh`)
5. Internal review — performance, memory, security, throughput, correctness
6. Cleanliness check — must be clean after audit
7. Deeper tests/benchmarks from audit observations
8. Run benchmarks again — prove the wins
9. If audit heavy → return to step 5
10. Documentation — update CHANGELOG, roadmap, docs
11. Version check — VERSION, Cargo.toml, recipe all in sync
12. Return to step 1
### Task Sizing
- **Low/Medium effort**: Batch freely — multiple items per work loop cycle
- **Large effort**: Small bites only — break into sub-tasks, verify each before moving to the next. Never batch large items together
- **If unsure**: Treat it as large. Smaller bites are always safer than overcommitting
### Refactoring
- Refactor when the code tells you to — duplication, unclear boundaries, performance bottlenecks
- Never refactor speculatively. Wait for the third instance before extracting an abstraction
- Refactoring is part of the work loop, not a separate phase. If a review (step 5) reveals structural issues, refactor before moving to step 6
- Every refactor must pass the same cleanliness + benchmark gates as new code
### Key Principles
- **Never skip benchmarks.** Numbers don't lie. The CSV history is the proof.
- **Tests + benchmarks are the way.** Minimum 80%+ coverage target.
- **Own the stack.** If an AGNOS crate wraps an external lib, depend on the AGNOS crate.
- **No magic.** Every operation is measurable, auditable, traceable.
- **`#[non_exhaustive]`** on all public enums.
- **`#[must_use]`** on all pure functions.
- **`#[inline]`** on hot-path functions.
- **`write!` over `format!`** — avoid temporary allocations.
- **Cow over clone** — borrow when you can, allocate only when you must.
- **Vec arena over HashMap** — when indices are known, direct access beats hashing.
- **Feature-gate optional deps** — consumers pull only what they need.
- **tracing on all operations** — structured logging for audit trail.
## DO NOT
- **Do not commit or push** — the user handles all git operations (commit, push, tag)
- **NEVER use `gh` CLI** — use `curl` to GitHub API only
- Do not add unnecessary dependencies — keep it lean
- Do not `unwrap()` or `panic!()` in library code
- Do not skip benchmarks before claiming performance improvements
- Do not commit `target/` or `Cargo.lock` (library crates only)
## Documentation Structure
```
Root files (required):
README.md — quick start, features, dependency stack, consumers, license
CHANGELOG.md — per-version changes (Added/Changed/Fixed/Removed)
CLAUDE.md — this file (development process, principles, DO NOTs)
CONTRIBUTING.md — fork, branch, make check, PR workflow
SECURITY.md — supported versions, scope, reporting
CODE_OF_CONDUCT.md — Contributor Covenant
LICENSE — GPL-3.0
docs/ (required):
architecture/
overview.md — module map, data flow, consumers, dependency stack
math.md — (if applicable) mathematical reference for algorithms/formulas
development/
roadmap.md — completed items, backlog, future features (demand-gated), v1.0 criteria
docs/ (when earned — not scaffolded empty):
adr/
NNN-title.md — architectural decision records (when non-obvious choices are made)
development/
threat-model.md — attack surface, mitigations (when security-relevant)
dependency-watch.md — deps to monitor for updates/CVEs
guides/
usage.md — patterns, philosophy, code examples
testing.md — test count, coverage, testing patterns
ADR format:
# NNN — Title
## Status: Accepted/Superseded
## Context: Why this decision was needed
## Decision: What we chose
## Consequences: Trade-offs, what changes
```
## CHANGELOG Format
Follow [Keep a Changelog](https://keepachangelog.com/):
```markdown
# Changelog
## [Unreleased]
### Added — new features
### Changed — changes to existing features
### Fixed — bug fixes
### Removed — removed features
### Security — vulnerability fixes
### Performance — benchmark-proven improvements (include numbers)
## [X.Y.Z] - YYYY-MM-DD
### Added
- **module_name** — what was added and why
### Changed
- item: old behavior → new behavior
### Fixed
- issue description (root cause → fix)
### Performance
- benchmark_name: before → after (−XX%)
```
Rules:
- Every PR/commit that changes behavior gets a CHANGELOG entry
- Performance claims MUST include benchmark numbers
- Breaking changes get a **Breaking** section with migration guide
- Group by module when multiple changes in one release
- Link to ADR if a change was driven by an architectural decision