principle-boundary-discipline

1# Boundary Discipline
2 
3Place validation, type narrowing, and error handling at system boundaries. Trust internal code unconditionally. Business logic lives in pure functions. The shell is thin and mechanical.
4 
5**Why:** Scattered validation is noisy, redundant, and gives a false sense of safety. Keep logic out of framework wiring so it can be tested without the framework.
6 
7**The pattern:**
8- **At boundaries** (CLI args, config files, external APIs, network protocols): validate, return errors, handle defensively.
9- **Inside the system:** typed data, error propagation, no re-validation. Trust the types.
10- **Across the boundary.** Expose domain concepts, not the boundary's private representation. Keep general-purpose mechanism inside and special-purpose policy at the edge.
11 
12**Applications:**
13 
14Validation and error handling:
15- Validate config at parse time (the boundary), not inside business logic
16- Parse raw data into domain types at the boundary
17- Do not re-export transport, storage, framework, or wire types through the public surface
18- No redundant nil checks deep in call chains if the boundary already validated
19 
20Code organization:
21- Business logic in pure functions with no framework dependencies
22- Parse functions: pure transforms from raw bytes to typed state
23- Prompt construction: structured state in, string out
24- Scoring and assessment: pure transforms from state to results
25 
26**The tests:**
27…