PRD: Migrate app to the redesigned UI and wire it to real mvp-shell logic

[Accelnorm]

Problem Statement

The current app UI is a single monolithic screen that has grown to cover chat, design-doc review, property review, CVLR spec approval, generation, and devnet deployment in one place. It is hard to navigate as a user and hard to evolve as a developer. A full redesign has been prototyped in a sibling project (redesigned-app) with a tab-based information architecture (Chat / Workspace / Explore), a reusable component library, vibe/pro modes, and offline affordances — but it runs entirely on mock data and is not connected to the real product logic.

Solution

Migrate the redesigned UI into the app repo (verified-spec-dev-app) and wire it to the existing real logic so it becomes the app's primary UI:

• The redesign's Expo Router routes and component library become the app's UI.
• All core flows (chat prompt capture, design-doc review/approval, verification-property review, CVLR spec approval, generation jobs, devnet deployment) are driven by the existing mvp-shell logic and backend instead of mock data.
• Vibe/Pro mode in the new UI maps to the existing workflow modes (vibe_coding / professional_development).
• The old monolithic UI stays temporarily reachable behind a legacy route until the redesign reaches parity, then gets removed in a follow-up.

BDD Scenarios

Feature: Redesigned app driven by real project state

  Scenario: App launches into the redesigned tab shell
    Given the app is launched
    Then the Chat, Workspace, and Explore tabs are shown
    And the legacy UI is not the default screen

  Scenario: Chat prompt captures a real project request
    Given I am on the Chat tab
    When I submit a project prompt
    Then the capture acknowledgement message appears in the chat
    And the Workspace tab shows a design doc derived from my prompt

  Scenario: Approving the design doc unblocks the next stage
    Given a design doc exists for my project
    When I approve the design doc in the Workspace review flow
    Then the workspace shows verification properties as the next action

  Scenario: Generation job status is reflected in the new UI
    Given the design doc, properties, and CVLR spec are approved
    When I start generation
    Then the job status shown in the Workspace matches the backend job status
    And status updates as the backend job progresses

  Scenario: Devnet deployment gating matches real blockers
    Given generation has not produced a deployable artifact
    Then the deploy action is blocked with the real blocker reason
    And the devnet demo warning is shown before any deployment

  Scenario: Mode toggle drives the real workflow mode
    Given I am in vibe mode
    When I switch to pro mode
    Then subsequent requests use the professional development workflow mode

  Scenario: State survives restart
    Given I have an in-progress project
    When the app restarts
    Then chat history, approvals, and job records are restored

  Scenario: Legacy UI remains reachable
    Given the redesigned UI is the default
    When I navigate to the legacy route
    Then the previous monolithic UI is shown and functional

Implementation Decisions

• Migration direction: the redesign's source (routes, components, theme, styles) is ported into the app repo; the app repo remains the canonical repo (it keeps git history, dev-client, android build, and backend logic). The redesign prototype repo is not developed further.
• The existing mvp-shell feature module (model, backend, generation, deployment, cvlr) remains the single source of truth for product logic and is not restructured.
• A new shell state adapter module is the core new work: a provider that replaces the redesign's mock app-state context and mock data module. It exposes the view-model the redesigned components consume (mode, offline flag, chat messages, design-doc and property review state, CVLR spec state, generation/deployment job views, blockers/next-action) and implements it by delegating to the existing mvp-shell state functions and backend client. The redesign UI talks only to this adapter, never to mocks or directly to backend fetch code.
• The adapter is written as pure state logic plus a thin React provider, so the state transitions are testable without rendering UI.
• Vibe/Pro mode in the redesign maps to the existing workflow-mode enum; the offline flag maps to real connectivity/backend-availability signals where available, with the manual toggle retained for demos.
• All core flows are wired to real logic in this migration (no mock-backed screens shipped as final). Explore-tab content may surface real project summaries from the backend project list; if the backend has no equivalent for a mock-only concept, the UI element is hidden rather than fed fake data.
• The old monolithic UI is kept temporarily behind a dedicated legacy route, unchanged, as a parity fallback. Its removal is a follow-up, not part of this PRD.
• Persistence/serialization of shell state continues through the existing serialize/restore functions; the adapter is responsible for restoring on launch.
• Dependency alignment: both projects are on the same Expo SDK / React Native / uniwind stack, so the port is source-level; any redesign-only dependencies are added to the app repo explicitly.
• The user runs Expo themselves; the implementation must not require restarting their dev server beyond normal fast refresh.

Testing Decisions

• Good tests exercise external behavior of the adapter (given prior state and a user action, the exposed view-model changes correctly), not implementation details like internal field shapes or call order.
• The shell state adapter is the module under test: prompt submission, approval gating (design doc → properties → CVLR → generation → deployment), mode switching, job normalization into view state, blocker derivation, and restore-on-launch.
• Prior art: the existing node:test + assert/strict test files for the mvp-shell modules in the app repo's tests directory; the adapter tests follow the same runner and style.
• No UI-rendering or delegated OpenCode UI test passes are in scope; the user validates the UI manually against their running Expo server.

Out of Scope

• Deleting the legacy monolithic UI (kept behind a legacy route; removal is a follow-up once parity is confirmed).
• Backend changes: the backend API is consumed as-is.
• New product features beyond what the redesign prototype and existing logic already express (no new Explore functionality invented where the backend has no data).
• Custom Solana program work (per workspace scope guard).
• Visual redesign changes: the redesign prototype's look and structure are ported as-is, not re-designed.

Further Notes

• The redesign prototype's mock data file is useful as a reference for the exact view-model shapes the components expect; it should inform the adapter's interface, then be deleted from the ported source.
• If parity gaps are found during the port (redesign screens with no backing logic), they should be logged in the specs repo's UI issue ledger rather than solved ad hoc.