GoingNinja Manual Knowledge Wiki logo
GoingNinja Manual Knowledge Wiki Lean MVP bootstrap documentation // Felix Rascher (WIP)

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
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.json before product-specific planning
  • REQUIREMENTS.json before architecture confirmation
  • READINESS_GATE.json before 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

7. Sources