Sarathi process

Two trees show how accepted documents lead to code; the learning loop shows how evidence changes what comes next.

Open live project status
Background = document type Spec Design Plan Code + tests
Level tag = work scope Product Feature Slice Status badge = workflow state
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.

Slice Spec
Approved
Slice spec Exact behavior and acceptance intent
Slice Design
Approved
Slice design / LLD Local contracts and test obligations
Slice Plan
Code-ready
Implementation plan PR-*, Red/Green, files to change, pass/fail checks
Slice Code + tests
Assessed
Code + tests Production behavior and executable evidence

2. Decompose only for unresolved uncertainty

This exceptional tree applies only when accepted intent plus one bounded plan is not enough. It is not the default route for a large feature or many screens.

Direct-to-code decision: first try inherited parent intent and one bounded Implementation plan for a reviewable increment or sequential UI slices. Create only the minimum delta artifact for an unresolved product decision, new contract, unaccepted material risk, independent feedback outcome, touch/integration conflict, or missing observable acceptance.

Neuring before / after: before, approved SRS, HLD, prototype, and runtime evidence still triggered a repeated feature Spec/Design chain. After, one shallow plan implements the first prototype-matching investor UI slice, excludes backend and BLE integration, and stops for stakeholder UI review. Later UI slices reuse the same plan unless feedback changes a real boundary.

Product Spec
Approved
Product spec Product AT/JT and system outcomes
Product Design
Approved
Product HLD System TEST obligations and environments
Product Plan
Approved
Breakdown plan Assigns work and parent test intent
WORK-FEATURE-ONE Product plan allocation → Feature child: sufficiently small leaf
Feature Spec
Approved
Feature 1 spec Feature AT/JT
Feature Design
Approved
Feature 1 design Feature composition TEST obligations
Feature Plan
Code-ready
Implementation plan Feature PRs and test allocation
Feature Code + tests
Assessed
Feature code + tests Feature AT, contract, and integration evidence
WORK-FEATURE-TWO Product plan allocation → Feature child: needs another breakdown
Feature Spec
Approved
Feature 2 spec Feature acceptance intent
Feature Design
Approved
Feature 2 design Boundaries and composition tests
Feature Plan
Needs breakdown
Feature breakdown plan Allocates slices and feature integration
WORK-SLICE-A Feature plan allocation → Slice child A
Slice Spec
Approved
Slice A spec Local behavior and acceptance intent
Slice Design
Approved
Slice A design / LLD Local contracts and boundary obligations
Slice Plan
Code-ready
Slice A plan Assigned parent and local tests
Slice Code + tests
Assessed
Slice A code + tests Unit, contract, and focused integration
WORK-SLICE-B Feature plan allocation → Slice child B
Slice Spec
Approved
Slice B spec Local behavior and acceptance intent
Slice Design
Approved
Slice B design / LLD Local contracts and boundary obligations
Slice Plan
Code-ready
Slice B plan Assigned parent and local tests
Slice Code + tests
Not started
Slice B code + tests Planned executable evidence
WORK-SYSTEM-INTEGRATION Product plan allocation → Integration slice child
Slice Spec
Approved
Integration slice spec References product AT/JT and cross-feature obligations
Slice Design
Approved
Integration slice LLD Environment, boundaries, fixtures, and test obligations
Slice Plan
Code-ready
Integration implementation plan PR ownership, environments, pass/fail checks, and requirement links
Slice Test code
Not started
System integration tests Executes product journeys, E2E, smoke, and system NFRs

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.

Assessed slice Working code, tests, and observed evidence
Stakeholder or system feedback Received, requested, unavailable, or not applicable
Parent documents Spec, design, plan, integration, and process
Next selected work Continue, revise, stop, cancel, split, reorder, or schedule a wave
Simplicity: delete, defer, collapse, or reuse evidence first Inside one slice: parallelism preferred Independent slices: use a bounded WIP wave only for a shared checkpoint Learning-dependent slices: wait for evidence