Planning To Launch

Bootstrap alone is not the whole method. If you do not yet have GitHub access, deployment access, domain ownership, and the required provider tokens or CLI sessions, start with Before You Start.

The intended sequence is:

1. confirm the provider baseline
2. confirm the product brief
3. start the active repo from goingninja-os
4. derive the concrete requirement set
5. derive the architecture requirements from that requirement set
6. pass the readiness gate
7. plan the first launch path inside that product repo
8. build in bounded slices
9. verify, audit, and launch

flowchart TD
    A[Provider Baseline] --> B[Product Brief]
    B --> C[Bootstrap Repo]
    C --> D[Requirements]
    D --> E[Architecture Requirements]
    E --> F[Readiness Gate]
    F --> G{Ready For Planning}
    G -- no --> B
    G -- yes --> H[Product Plan]
    H --> I[Implementation Slices]
    I --> J[Verification]
    J --> K[Audit]
    K --> L{Accepted}
    L -- no --> H
    L -- yes --> M[Launch]

flowchart TD
    A[Provider Baseline] --> B[Product Brief]
    B --> C[Bootstrap Repo]
    C --> D[Requirements]
    D --> E[Architecture Requirements]
    E --> F[Readiness Gate]
    F --> G{Ready For Planning}
    G -- no --> B
    G -- yes --> H[Product Plan]
    H --> I[Implementation Slices]
    I --> J[Verification]
    J --> K[Audit]
    K --> L{Accepted}
    L -- no --> H
    L -- yes --> M[Launch]

Flow: canonical product path from brief to launch.

1. Provider Baseline

Before product-specific briefing starts, the provider and domain baseline must already be explicit.

Use Before You Start as the canonical setup baseline. This page only depends on that baseline being confirmed:

• repo owner and deployment owner are known
• preview hostname and DNS owner are known
• Cloudflare Access ownership for the preview host is known
• the required CLI sessions or automation tokens are either ready or explicitly still missing

Bootstrap can create repo structure. It cannot invent provider ownership, domain control, or billing responsibility.

2. Product Brief First

Before product-specific planning starts, answer the product brief explicitly.

The minimum required questions are:

• what single product is being built?
• who is the first real user or customer?
• what must become true at launch?
• what is the first user path?
• what is the first operator path?
• what is the first proof path?
• what is the release boundary?
• what is explicitly out of scope?
• what concrete requirements are needed for the first launch slice?

Do not answer these from memory, from an older repo, or from intuition. If the product is not yet known well enough to answer them, the repo stays in briefing.

3. Bootstrap

Once the product brief is explicit, bootstrap the active repo from goingninja-os.

Bootstrap provides the deterministic file contract. It does not authorize guessed product scope or guessed architecture.

4. Requirement Set

The requirement set is the first concrete translation of the product brief into buildable obligations.

The requirement set should answer at least:

• which functional requirements are mandatory for the first launch slice
• which non-functional requirements are mandatory for the first launch slice
• which operational requirements are mandatory for the first launch slice
• which content requirements are mandatory for the first launch slice
• which integrations are actually required
• which gaps are explicit launch blockers if they remain missing
• which items are only nice to have
• which questions are still open

This is the right place for exclusion criteria. If an item is required for launch or for the first planning slice, it belongs here. If it is not required yet, it belongs in non-goals or nice to have, not as implied scope.

5. Architecture Requirements

Product requirements are not enough on their own. They must produce explicit architecture requirements.

That derived architecture layer should answer at least:

• what runtime surfaces exist
• what state and data must exist
• which write and read paths are required
• what the auth boundary is
• which providers are actually needed
• what the deployment boundary is
• what observability and verification the slice requires
• what is architecturally explicitly out of scope

Do not start product-specific planning before this derived architecture layer is explicit and checked against the requirement set.

6. Readiness Gate

After the product brief, requirement set, and architecture requirements exist, run a binary readiness gate.

The readiness gate is not prose. It answers one question:

• is the first planning slice explicit enough that the repo can move from briefing to planning without guessing?

The repo is not ready for planning if any of these are still true:

• a required product brief answer is still missing
• a required requirement class is still missing
• architecture is still implicit
• the first planning slice is still ambiguous
• a critical vendor assumption is still unverified
• a global wiki or OS rule is wrong and the product would need a local workaround

If any of these fail, stop. Fix the missing requirement or fix the global rule first.

The canonical readiness inventory is fixed as:

Those IDs are not ad-hoc labels. They come from the repo contract in goingninja-os/templates/project-repo/READINESS_GATE.json.

7. Goal Definition

Start the actual product plan with one hard statement:

• what product is being built
• for whom
• what must become true at launch

The goal must describe the first real outcome, not a platform dream.

Examples of acceptable goal framing:

• one gated operator tool for a narrow internal workflow
• one member product with one clear reading or archive path
• one preview surface that can be audited and launched safely

Bad goal framing:

• "build the whole system"
• "make it scalable later"
• "set up all future possibilities"

8. Scope

Scope must stay explicit before bootstrap starts.

Required:

• first user path
• first operator path
• first proof path
• first release boundary

The normal question is not "what could this product become?" It is "what is the smallest launch-shaped version worth proving?"

9. Non-Goals

Non-goals are part of the product contract.

Write down what will not be solved in the first launch window:

• deferred feature families
• postponed provider swaps
• postponed automation
• postponed redesigns
• postponed platform extraction

This keeps the product repo lean and stops planning drift from pretending to be progress.

10. First Product Planning

After bootstrap, the product repo owns the first concrete plan.

That plan should answer:

• what the first launchable slice is
• what evidence will prove it
• what the current blockers are
• what the next bounded implementation block is

In a generated repo, PLAN.md should mirror this path:

1. goal definition
2. launch outcome
3. in scope
4. out of scope
5. bootstrap baseline
6. implementation slices
7. verification
8. audit
9. launch gate

9a. Instruction Files Come Next

The initial product plan also determines the first instruction surface for the tools.

That means:

• AGENTS.md carries the shared repo contract
• CLAUDE.md and GEMINI.md stay thin and point back to the shared contract
• product-specific instruction details must come from the current plan, scope, and launch boundary
• vendor-specific behavior should be checked against current manufacturer documentation, not guessed from memory

The product repo should not invent a new instruction system locally if the global system already defines the rule.¹

11. Implementation Slices

A good slice has:

• one concrete user or operator outcome
• one owner
• one verification path
• one obvious merge boundary

Examples:

• OTP request and verification end to end
• one preview-protected reading surface
• one worker dispatch path with explicit failure visibility

Bad slices:

• "finish backend"
• "do UX"
• "make it production ready"

12. Verification

Every slice needs explicit verification before it counts.

Verification should include only what the current slice needs, for example:

• typecheck
• tests
• route checks
• state checks
• preview checks
• provider smoke checks

Verification is where "should work" becomes visible evidence.

13. Audit

Audit happens after a coherent verified slice or batch, not continuously on moving code.

The bounded rule is:

1. freeze the current snapshot
2. declare the scope class
3. record the lane in AUDIT_STATE.json
4. run the external audit pair on that snapshot
5. close the real findings
6. move to closure mode when repeated passable appears

Audit exists to challenge the product path, not to replace it. It starts only after the active product and architecture requirements are explicit and complete.

AUDIT_STATE.json is the mechanical exit contract:

• it declares the lane scope and the frozen snapshot ref
• it counts normal, closure, and confirm rounds
• capped lanes fail if they exceed their numeric budget
• system lanes block for a prompt/process rewrite after two repeated passable verdicts

14. Launch

Launch is the final boundary, not a mood.

Launch readiness means:

• the intended launch scope is implemented
• verification is green for that scope
• audit state is passable or passed for that scope
• state and decisions are synchronized
• boundaries to preview, live, and providers are explicit

If one of those is missing, the product is still pre-launch.

15. What Stays Global vs Local

Global repos own:

• bootstrap
• invariants
• shared contracts
• proof standards
• audit mechanics
• platform boundaries

The product repo owns:

• product goal
• product plan
• product runtime
• product-specific secrets and deploy config
• product launch boundary

If a product build exposes a mistake in:

• the wiki
• the bootstrap contract
• the template
• the shared instruction model

then the fix belongs in the global source first.

Do not bend the product repo around a known global mistake just to keep momentum.

That split is the whole point. The product should not have to invent the platform, and the platform should not hide inside the product.

16. Minimum Sequence

The shortest correct path is:

1. provider baseline
2. product brief
3. bootstrap
4. requirement set
5. architecture requirements
6. readiness gate
7. first product plan
8. implementation slices
9. verification
10. audit
11. launch

If this sequence is missing, the repo may still contain code, but it is not yet following the GoingNinja product model.