Product Proof

A proof page is not only an internal status log.

1. Product Proof Must Teach The System

A proof page is not only an internal status log.

It must help a first-time reader understand:

• what is being proven
• which example product is used
• which steps the system follows
• which evidence already exists
• which learnings were written back globally

If a proof page reads like repo folklore, it is not doing its job.

2. Product Requirements Must Be Confirmed Before Architecture

GoingNinja now treats Requirements as a separate global stage between Product Brief and Architecture Requirements.

That separation prevents two recurring failures:

• hiding launch requirements inside product prose
• inventing architecture before the real launch need is explicit

3. Proof Cases Must Fix Global Contracts First

If a live product-proof case exposes a missing step, unclear gate, or broken template rule, the product repo should not absorb that defect locally.

The correct sequence is:

1. fix the global manual
2. fix the global OS template
3. rerun the product on the corrected contract

That is what turns one project into platform proof.

4. Diagram Readability Beats Diagram Density

If a process diagram becomes readable only after the browser shrinks the full SVG, the diagram is already wrong.

GoingNinja now treats diagram readability as a shared contract:

• sequential flows default to top-down layout
• labels stay short and wrap intentionally
• the SVG keeps its natural width and scrolls when needed
• the reader should never need to decipher tiny scaled text

5. Provider Baseline Must Be Explicit Before Bootstrap

Product planning cannot start from repo shape alone.

Before bootstrap or deployment can be treated as real work, the system needs an explicit provider baseline:

• GitHub owner
• deployment owner
• DNS owner
• preview-vs-live decision
• CLI session or automation token availability
• billing ownership

If those are missing, the right fix is not to guess through them in the product repo. The right fix is to document the prerequisite globally first.

6. Long Proof Pages Need Guided Navigation

Proof pages are usually longer than normal docs pages because they combine:

• goal
• example product
• setup baseline
• status
• evidence
• learnings

That means proof pages need guided local navigation.

If a proof page is long enough to teach a process, the reader should be able to move through its headings directly from the sidebar instead of scanning one long page blind.

7. New Process Rules Must Be Checked Before They Are Canonized

Not every plausible process idea deserves to become a platform rule.

Before a new rule is written into the wiki, template, or bootstrap path, compare it against:

• current official vendor documentation
• stable delivery or readiness best practice
• the existing platform contract

Do not promote a fresh idea straight from chat into the global system without that check.