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-* = assigned work WORK-EXAMPLE Parent plan → Focused child work

Only work that is ready to implement invokes /code-create. Approval means safe enough for the next learning step, not frozen or final.

Use lighter review for a small reversible change, normal review by default, and stricter review when failure could cause serious harm. Start with the smallest solution for current users. Process records stay outside product code.

1. PR-sized leaf

No breakdown is needed.

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

2. Split work only when a question blocks implementation

This larger tree applies only when the approved requirements, design, and one implementation plan are not enough. A large feature or many screens is not, by itself, a reason to add more documents.

Start from the approved requirements and design with one short implementation plan. Add another document only when a specific unanswered product decision, external contract, serious risk, ownership conflict, or missing acceptance criterion prevents safe implementation.

Neuring before / after: before, approved requirements, architecture, 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 architecture System TEST obligations and environments
Product Plan
Approved
Breakdown plan Assigns work and parent test intent
WORK-FEATURE-ONE Assigned by the product plan → 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
Ready
Implementation plan Feature changes and required tests
Feature Code + tests
Assessed
Feature code + tests Feature AT, contract, and integration evidence
WORK-FEATURE-TWO Assigned by the product plan → 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 Assigned by the feature plan → Slice child A
Slice Spec
Approved
Slice A spec Local behavior and acceptance intent
Slice Design
Approved
Change A design Local contracts and boundary obligations
Slice Plan
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 Assigned by the feature plan → Slice child B
Slice Spec
Approved
Slice B spec Local behavior and acceptance intent
Slice Design
Approved
Change B design Local contracts and boundary obligations
Slice Plan
Ready
Slice B plan Assigned parent and local tests
Slice Code + tests
Not started
Slice B code + tests Planned executable evidence
WORK-SYSTEM-INTEGRATION Assigned by the product plan → Integration slice child
Slice Spec
Approved
Integration slice spec References product AT/JT and cross-feature obligations
Slice Design
Approved
Integration design Environment, boundaries, fixtures, and test obligations
Slice Plan
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 group parallel work
Simplicity: delete, defer, collapse, or reuse evidence first Inside one change: independent tasks may run together Separate changes: group them only when they share a review point Dependent changes: wait for the result they depend on