Lean Implementation
This page explains what lean means in GoingNinja.
It does not mean:
- fewer features at any cost
- rushed code
- no structure
It means:
- the smallest justified slice
- the smallest justified architecture
- one clear owner per contract
- no repeated bug class left to return under a different filename
flowchart TD A["Problem"] --> B["Smallest launch slice"] B --> C["One contract owner"] C --> D["Build only that slice"] D --> E["Verify"] E --> F["Audit"] F --> G["Write back learnings"]
Show diagram source
flowchart TD
A["Problem"] --> B["Smallest launch
slice"]
B --> C["One contract
owner"]
C --> D["Build only
that slice"]
D --> E["Verify"]
E --> F["Audit"]
F --> G["Write back
learnings"]Flow: lean delivery removes unjustified complexity before it spreads.
1. Why Lean Exists
Lean implementation exists because software drifts faster than teams notice.
The common failure pattern is:
- solve one local problem
- add one helper
- add one second owner of the same rule
- patch the same symptom in a second place
- lose the obvious source of truth
That makes code harder to teach, slower to audit, and easier to break.
GoingNinja therefore optimizes for:
- explicit contracts
- small bounded slices
- fail-fast checks
- global fixes for global bug classes
2. What Lean Means Here
Lean in this system means:
- one source of truth per concern
- shared things live once
- generated files are outputs
- state is explicit before planning
- planning is explicit before implementation
- implementation is smaller than ambition
The goal is not “minimal lines of code.” The goal is minimal unjustified complexity.
3. The Core Rules
3.1 One Owner Per Contract
If a routing rule, layout rule, CSP rule, or metadata rule exists, it should have one canonical owner.
If two files carry the same truth, drift is already underway.
3.2 Shared Bugs Must Be Fixed At The Shared Owner
If the failure comes from a shared layout, renderer, route contract, or state renderer, the fix belongs there.
Do not close a repeated bug class with:
- one page-specific CSS patch
- one-off generated output edits
- multiple manual copies of the same fix
3.3 Build The Smallest Launch-Shaped Slice
GoingNinja does not start with broad “build everything” plans.
It starts with the smallest slice that still looks like the real product.
That keeps three things under control:
- scope
- audit cost
- review clarity
3.4 Fail Fast
Lean code should fail early on structural contradictions:
- missing required state keys
- route collisions
- unresolved placeholders
- missing provider readiness
- invalid preview or launch boundaries
3.5 Learnings Must Become Contracts
If an audit or proof case exposes a repeated failure class, the lesson must be written back into:
- the manual
- the OS template
- the relevant invariant or check
If the lesson stays only in chat, the system has not improved.
4. How The System Enforces Lean
GoingNinja does not rely on memory alone. It uses explicit guards.
Examples:
PRODUCT_BRIEF.jsonbefore product-specific planningREQUIREMENTS.jsonbefore architecture confirmationREADINESS_GATE.jsonbefore implementation- rendered state views generated from JSON, not maintained by hand
- shared templates in
goingninja-os - external audits with caps and closure rules
That is why lean is a system property here, not only a coding style.
5. Tagnova Example
The Tagnova proof case shows the rule in practice.
The first active slice is only:
- landing
- why Tagnova
- today’s edition
It is not yet:
- login
- save and archive
- operator update tooling
That split is lean on purpose.
Why:
- the public reading surface can be verified on its own
- the preview and deployment contract can be made explicit before wider complexity arrives
- later slices stay accountable to a real first slice instead of being buried in a broad MVP blob
The lean shape is visible in the active plan itself:
## Slice 1
- landing
- why Tagnova
- today's edition
- visible city split for Vienna, Munich, and London
- source-link contract
- calm mobile and desktop reading experience
And the gate stays explicit before that slice is allowed to count:
{
"id": "RG4",
"name": "first_launch_slice_explicit",
"status": "pass",
"evidence": "The first planning slice is explicit: public reading surface first, member save and archive second, operator update path third."
}
That is the practical meaning of lean in this system:
- not broad ambition first
- one launch-shaped slice first
- then verification and audit on that slice
6. What Lean Prevents
Lean implementation mainly prevents these failure modes:
| Failure mode | Lean response |
|---|---|
| one product starts working around a global mistake | fix the global source first |
| a feature grows before the proof chain is stable | cut back to one bounded slice |
| the same truth is kept in parallel files | pick one owner and render the rest |
| the builder claims closure too early | verify and audit first |
| UI defects get patched page by page | fix the shared contract |