Next Level Startup

`$assumption-tracker` - create/update `research/assumption-tracker.md` because foundational research and `research/mvp-gap.md` exist, but there is no living assumption register to rank the next validation risks.

`$customer-feedback` - create/update `research/customer-feedback.md` because Phase 6 is complete and `research/mvp-gap.md` identifies willingness-to-pay interviews with activated founders as remaining first-sale evidence.

`$landing-copy` - refresh `research/landing-copy.md` because ICP, journey, GTM, and monetization research are newer (`research/landing-copy.md` 2026-05-04 13:46:48; newest upstream `research/monetization.md` 2026-05-07 13:44:56).

`$metrics` - refresh `research/metrics.md` because it is older than `research/journey-map.md` (`research/metrics.md` 2026-04-15 12:37:52; `research/journey-map.md` 2026-05-07 13:33:39).

`$spec-drift fix all` - refresh implementation/spec alignment because source and task history changed after `specs/drift-report.md` (`specs/drift-report.md` 2026-05-07 13:57:19; Phase 6 completion docs 2026-05-08).

`$ui-interview` - define and execute a complete UI/UX pass across every interface before further product build work. Scope must include public marketing/home, sign-in/auth shell, onboarding, workspace overview, assumptions, experiments, evidence, guidance, claims, claim detail, reviewer queue/detail, internal reports, public directory/profile, public-interest CTA, debug/admin surfaces, empty/loading/error states, responsive behavior, navigation, accessibility, and browser verification. This supersedes the documentation queue below as the next priority.

Add structured interview evidence or a deliberately minimal interview-entry layer that captures the fields reviewers and founders need most.

Persist the onboarding first gate: create/update ICP, problem hypothesis, initial risky assumption, recruiting target, and optional first experiment from onboarding data.

Run complete UI/UX passes across all interfaces before further product build work: public marketing/home, auth shell, onboarding, workspace, assumptions, experiments, evidence, guidance, claims, reviewer operations, internal reports, public directory/profile, public-interest CTA, debug/admin surfaces, states, responsive behavior, navigation, accessibility, and browser verification.

Run customer-feedback and willingness-to-pay interviews with activated founders before enabling checkout.

All phase tests pass.

All phase tests pass.

Check monorepo heuristics before deciding whether to include the Monorepo Parallel-Work Safety section.

Confirm flat research scope and required ICP inputs.

Execute Phase 6 to make private beta operating data durable for concierge launch decisions.

Internal reporting includes durable launch-readiness metrics without leaking private evidence or raw beta feedback.

Internal reporting includes durable launch-readiness metrics without leaking private evidence or raw beta feedback.

Map product gaps to journey stage, market impact, implementation evidence, closure metric, and spec status.

No regressions in previous phase tests.

No regressions in previous phase tests.

Operator-created records can capture acquisition source, readiness decisions, beta feedback/willingness-to-pay outcomes, and reviewer time logs through lightweight internal entry paths, server actions, APIs, or seed helpers.

Operator-created records can capture acquisition source, readiness decisions, beta feedback/willingness-to-pay outcomes, and reviewer time logs through lightweight internal entry paths, server actions, APIs, or seed helpers.

Provision workflow orchestration policy into `CLAUDE.md` and `AGENTS.md`, preserving unrelated content and ensuring the block appears exactly once per file.

Public-interest submissions survive process restart/deploy and dedupe by normalized `email + intent + startupSlug + source`, updating `submissionCount` and `lastSeenAt`.

Public-interest submissions survive process restart/deploy and dedupe by normalized `email + intent + startupSlug + source`, updating `submissionCount` and `lastSeenAt`.

Read ICP, metrics, journey map, GTM, monetization, competitive analysis, specs, task docs, and implemented app surfaces.

Reconcile stale research, spec, and task docs so the next plan starts from current code reality.

Repository, API, reporting, privacy, typecheck, and build verification pass for the affected surfaces.

Repository, API, reporting, privacy, typecheck, and build verification pass for the affected surfaces.

Step 1.1: Add the root app scaffold and write failing route tests for the public landing shell, sign-in entry point, and protected founder workspace shell in `app/`, `src/features/shell/`, and `tests/routes/`. **automated**

Step 1.10: Verify Phase 1 acceptance criteria: the app runs locally, a founder can reach a protected workspace shell after sign-in, core entities persist, and non-production storage/email paths are exercisable. All Phase 1 tests pass with no regressions in earlier steps. **automated**

Step 1.2: Implement the initial application shell, shared layout tokens, and placeholder route modules to satisfy the shell tests in `app/`, `src/components/`, and `src/features/shell/`. **automated**

Step 1.3: Introduce typed domain models and repository/service interfaces for founders, startups, ICPs, assumptions, experiments, evidence, claims, and reviews in `src/domain/` and `src/server/`. **automated**

Step 1.4: Integrate the selected auth provider behind an adapter and enforce workspace protection in `src/server/auth/`, `proxy.ts`, and `app/(app)/`. **automated**

Step 1.5: Add database connectivity, schema definitions, and a local seed/debug path in `src/server/db/` and `scripts/`. **automated**

Step 1.6: Add evidence upload storage integration behind a storage client seam in `src/server/storage/` and `app/api/uploads/`. **automated**

Step 1.7: Add outbound email delivery plumbing for auth and review notifications in `src/server/email/` and related templates. **automated**

Step 1.8: Add a minimal internal admin/debug surface for inspecting founders, startups, and claims in `app/(internal)/`. **automated**

Step 1.9: Run the Phase 1 test suite plus targeted smoke checks for auth, database, storage, and email seams; fix regressions before closing the phase. **automated**

Step 2.1: Write failing integration tests for founder onboarding, startup workspace creation, assumption prioritization, experiment creation, and interview logging in `tests/onboarding/` and `tests/workspace/`. **automated**

Step 2.2: Build the onboarding flow for track, startup name, ICP, problem hypothesis, and current stage estimate in `app/(app)/onboarding/` and `src/features/onboarding/`. **automated**

Step 2.3: Build the private founder workspace overview and single-startup context in `app/(app)/workspace/` and `src/features/workspace/`. **automated**

Step 2.4: Implement assumption capture, ranking, and next-test recommendation in `src/features/assumptions/`. **automated**

Step 2.5: Implement experiment planning centered on discovery interviews with track-aware defaults in `src/features/experiments/`. **automated**

Step 2.6: Implement structured interview logging, uploads, and external evidence links in `src/features/evidence/` and `app/api/evidence/`. **automated**

Step 2.7: Expose stage definitions, evidence expectations, and lightweight reminders inside the founder workspace in `src/features/guidance/`. **automated**

Step 2.8: Run Phase 2 workflow tests and targeted regression coverage for Phase 1 shells, auth protection, and persistence. **automated**

Step 2.9: Verify a founder can complete onboarding, create assumptions and an experiment, log interviews with evidence, and understand the first milestone requirements. All Phase 2 tests pass with no regressions in earlier phases. **automated**

Step 3.1: Write failing tests for claim submission, reviewer queue access, decision handling, audit trails, and notification triggers in `tests/claims/` and `tests/reviewer/`. **automated**

Step 3.2: Implement milestone claim submission tied to experiments and evidence in `src/features/claims/` and `app/(app)/claims/`. **automated**

Step 3.3: Implement the reviewer queue, track-aware rubric presentation, and decision workflow in `app/(internal)/reviews/` and `src/features/reviews/`. **automated**

Step 3.4: Persist review outcomes, rationales, and claim-state transitions with audit history in `src/server/reviews/` and `src/server/db/`. **automated**

Step 3.5: Expose founder-facing review status/history and send email notifications for submission and decision changes. **automated**

Step 3.6: Run reviewer and founder claim-flow tests plus regression coverage for onboarding, evidence logging, and shell access. **automated**

Step 3.7: Verify claims can be submitted, reviewed, audited, and surfaced back to founders within the intended workflow. All Phase 3 tests pass with no regressions in earlier phases. **automated**

Step 4.1: Write failing tests for public profile publication gates, reviewed summary rendering, directory filters, and beta/design-partner CTA handling in `tests/public/`. **automated**

Step 4.2: Implement the approved-profile publication gate and public profile pages in `app/(public)/startups/` and `src/features/public-profile/`. **automated**

Step 4.3: Implement directory browse/filter experiences for track, stage, geography, momentum, and newest approved milestones in `app/(public)/directory/`. **automated**

Step 4.4: Implement reviewed evidence summaries, spotlight capability, and public CTA capture in `src/features/public-directory/` and `app/api/public-interest/`. **automated**

Step 4.5: Run public-experience tests plus regressions for private workspace, claims, and review visibility boundaries. **automated**

Step 4.6: Verify only approved startups are publicly discoverable, private raw evidence stays hidden, and the directory supports trust-forward browsing. All Phase 4 tests pass with no regressions in earlier phases. **automated**

Step 5.1: Write failing tests for onboarding guidance improvements, reminder behavior, reviewer SLA reporting, and subscription-readiness hooks in `tests/operations/` and `tests/reporting/`. **automated**

Step 5.2: Refine onboarding education, in-product guidance, and reminder loops based on concierge-beta workflows in `src/features/guidance/` and `src/features/engagement/`. **automated**

Step 5.3: Add reporting for onboarding completion, interview activity, claim rates, approval rates, and reviewer SLA performance in `app/(internal)/reports/` and `src/server/reporting/`. **automated**

Step 5.4: Add pricing/package hooks and readiness flags without turning on billing flows in `src/features/billing/` and `src/config/`. **automated**

Step 5.5: Tighten reviewer audit tooling and evidence-standard guardrails for broader beta operations. **automated**

Step 5.6: Run operations/reporting tests and targeted regressions across founder, reviewer, and public flows. **automated**

Step 5.7: Verify the team can measure workflow health, operate review quality consistently, and stage the product for future paid plans. All Phase 5 tests pass with no regressions in earlier phases. **automated**

Step 6.1: Write failing tests for durable public interest and beta operating records. **automated**

Step 6.2: Add Phase 6 persistence schema and migrations. **automated**

Step 6.3: Replace memory-only public-interest persistence with durable repository behavior. **automated**

Step 6.4: Add beta operating record repositories and lightweight entry helpers. **automated**

Step 6.5: Extend operations reporting and internal dashboard for launch-readiness metrics. **automated**

Step 6.6: Remove or rename the misleading public Momentum control as a narrow directory cleanup. **automated**

Step 6.7: Run Phase 6 validation and regressions, then perform only concrete cleanup found by validation. **automated**

The public Momentum control is either renamed/removed in the touched public directory path, or explicitly left unchanged with a documented reason if it would expand the phase.

The public Momentum control is either renamed/removed in the touched public directory path, or explicitly left unchanged with a documented reason if it would expand the phase.

Verify final file contents after provisioning.

Verify the output satisfies the `mvp-gap` skill contract, then commit and push the documentation changes.

Write `research/mvp-gap.md` with a prioritized build sequence, downstream impact check, and next-step routing.