tomevault-io Harness Architecture Review
Use this skill to surface architecture friction before proposing refactors.
Workflow skills guide process. Ownership skills still decide writable boundaries.
Process
- Read
AGENTS.md,agent/codemap.yml,docs/architecture/north-star.md, and accepted ADRs in the area. - Explore code and tests before judging architecture.
- Identify where understanding requires bouncing across many shallow modules.
- Apply the deletion test to suspected pass-through modules.
- Check whether a seam has real variation, testing value, or topology-late value.
- Check ownership boundaries before recommending changes.
- Present candidates only. Do not edit first.
Candidate Format
For each candidate, report:
- files or owner areas involved
- problem and evidence
- why the current module or seam is shallow
- proposed deeper interface in plain English
- benefit in leverage, locality, and testability
- ADR or north-star conflict, if any
- risk and suggested verification
Ask which candidate to explore before designing interfaces or changing code.
Repository-Specific Rules
- A service library can be a semantic boundary without becoming a process boundary.
- A Rust trait is not automatically a useful seam.
- Platform metadata must not absorb service-local semantics.
- Server handlers adapt protocols; they do not own domain rules.
- Worker reliability claims require executable retry, checkpoint, dedupe, replay, and recovery evidence at the claimed level.
Source: openclosed-org/axum-harness — distributed by TomeVault.