Sarathi process
Two trees show how accepted documents lead to code; the learning loop shows how evidence changes what comes next.
WORK-* = parent allocation
WORK-EXAMPLE Parent plan
→ Child record or chain
Only code-ready leaves invoke /code-create. Approval means
safe enough for the next learning step, not frozen or final.
Lean, Standard, and High-assurance change evidence depth, not the loop. An eligible Lean slice can use one compact change record; Standard work uses the full child chain. Start with the smallest current-consumer solution; process evidence stays outside product architecture. Bounded slices default to at most three implementation PRs. There are no line-count targets.
1. PR-sized leaf
No breakdown is needed.
PR-*, Red/Green, files to change, pass/fail checks
2. Product that needs breakdown
Each branch repeats until it reaches a code-ready leaf.
WORK-FEATURE-ONE
Product plan allocation
→
Feature child: sufficiently small leaf
WORK-FEATURE-TWO
Product plan allocation
→
Feature child: needs another breakdown
WORK-SLICE-A
Feature plan allocation
→
Slice child A
WORK-SLICE-B
Feature plan allocation
→
Slice child B
WORK-SYSTEM-INTEGRATION
Product plan allocation
→
Integration slice child
Integration is incremental: slices prove boundaries, features prove local composition, and explicit integration slices prove cross-feature behavior. Requirement links show ownership; execution results prove outcomes.
3. Inspect and adapt
Every assessed slice can change its parent documents and the next selected work.