> Original design reference. The current PHP implementation adds MySQL persistence, server-enforced accounts, Groq workflows and PDF export. See [current implementation](IMPLEMENTATION.md) for the release scope.

# CynarisLaunch — MVP build specification

## Goal and user
Primary users: Founder or small startup team.

Core journey: Working assumption → validation experiment → recorded evidence → roadmap decision → pitch.

The prototype implements the sample journey in the browser. Production scope includes persistence, validation, identity, authorisation and service integration. Live AI outputs must be explicitly labelled and evaluated.

## Screens
| ID | Screen | Route | Primary behaviour |
|---|---|---|---|
| LAUNCH-01 | Overview | `/apps/launch/?screen=overview` | Review the startup context and experiments in motion. |
| LAUNCH-02 | Business canvas | `/apps/launch/?screen=canvas` | Edit nine working hypotheses. |
| LAUNCH-03 | Validation plan | `/apps/launch/?screen=validation` | Review assumptions and plan a discovery experiment. |
| LAUNCH-04 | Experiments | `/apps/launch/?screen=experiments` | Create experiments, record evidence and update status. |
| LAUNCH-05 | Roadmap | `/apps/launch/?screen=roadmap` | Create milestones and move them through planning stages. |
| LAUNCH-06 | Pitch outline | `/apps/launch/?screen=pitch` | Edit the narrative and inspect a pitch preview. |
| LAUNCH-07 | Startup settings | `/apps/launch/?screen=settings` | Edit startup name, audience and stage. |

## Data requirements
- Startup, CanvasEntry, Experiment, Milestone, PitchVersion.
- Canvas entries are hypotheses unless supported by linked evidence.
- Experiment evidence and interpretation should be separate fields in production.
- Pitch versions should preserve source references for any traction, market or financial claim.

## Proposed API surface
- `GET/PUT /startup`
- `GET /startup/canvas; PATCH /startup/canvas/:category`
- `GET/POST /experiments; PATCH /experiments/:id`
- `GET/POST/PATCH /milestones`
- `GET/POST /pitch-versions`

All endpoints inherit the workspace-scoping, pagination, validation, error and audit rules in BUILD-HANDOFF.md. Schemas in models.ts are starting contracts, not complete database migrations.

## Required states
- Loading: stable skeleton or progress indicator with an accessible status message.
- Empty: explain the missing record and offer the first useful action.
- Invalid input: inline field error; preserve all valid inputs.
- Service failure: preserve context and offer a safe retry.
- Forbidden or expired access: explain the restriction without leaking record contents.
- Success: update the visible record and dependent summaries, then announce the change.
- Concurrent edit: surface conflict and let the user review the current version.

## Acceptance criteria
- [ ] Canvas edits preserve field validation and revision history.
- [ ] An experiment has a hypothesis, method and success signal before it is marked ready.
- [ ] Evidence can be recorded without automatically declaring the idea validated.
- [ ] Roadmap movement updates the selected milestone without losing its description.
- [ ] Pitch preview reflects edits and clearly distinguishes unverified claims.
- [ ] No financial forecast, funding promise or demand validation is implied by template output.

## AI implementation boundary
AI calls belong on the server behind task-specific contracts. Log model/prompt version and evaluation outcome without retaining sensitive content unnecessarily. Support cancellation, timeout and a non-AI fallback. Human review remains part of consequential decisions. The current prototype uses deterministic sample logic, not a model.

## Deferred scope
Production integrations, billing, real notifications, operational analytics, advanced collaboration and broad automation are not implied by this prototype. Define them after the core workflow is validated with users.