Unclassified

Complete Domain Shells Implementation Plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Make apps/web render complete, differentiated domain shells for every SpineWorkspace projection using the existing donor applications as the view inventory while preserving PR #127 routing and the Gateway → Projection Engine → Spine boundary.

Architecture: Keep apps/web as the single authenticated SpineWorkspace runtime. Extend the PR #127 projection registry with donor provenance and complete view inventories, then route every projection view through one reusable DomainViewShell that supports dashboard, table, board, calendar, feed, canvas, signals, and execution-preview surfaces. Donor auth, direct Supabase/API calls, and independent app shells are not migrated.

Tech Stack: Next.js 16, React 19, TypeScript, Tailwind v4, shadcn/Radix primitives already present in apps/web, Vitest.

Global Constraints

  • Preserve PR #127 hostname → ProjectionId routing and apps/web common shell.
  • Do not deploy donor applications independently.
  • Do not import donor auth, Supabase clients, provider SDKs, or direct database access.
  • Keep real runtime data behind Gateway → Projection Engine → Spine.
  • This pass completes domain shells and view/canvas coverage; skills/agents/workflows render as declarative execution previews only.
  • Demo content must be deterministic, typed, visibly non-persistent, and safe for preview use.
  • Preserve accessibility and responsive behavior.

Task 1: Projection completion contract

Files:

  • Modify: apps/web/lib/projection-registry/types.ts
  • Create: apps/web/lib/projection-registry/donor-catalog.ts
  • Create: apps/web/lib/projection-registry/complete-manifest.ts
  • Modify: apps/web/lib/projection-registry/registry.ts
  • Test: apps/web/lib/projection-registry/completion.test.ts

Interfaces:

  • Consumes: existing ProjectionManifest, ViewManifest, PROJECTION_REGISTRY.

  • Produces: DonorSource, richer ViewManifest metadata, completeProjectionManifest(base), and a registry where every projection has a donor-derived view inventory.

  • Write failing tests asserting all 18 projections have unique paths, donor provenance, and materially complete view counts; assert key Account Success, TAS, BI, Marketing, Sales, Book of Records, and Brandstore views exist.

  • Verify the tests fail against PR #127's shallow manifests.

  • Add typed donor provenance and shell metadata to ViewManifest without changing the existing skills/agents/workflows contract.

  • Add donor-derived view catalogs and manifest completion logic that merges existing PR #127 views with donor inventories.

  • Update registry.ts so consumers receive completed manifests.

  • Re-run projection tests.

Task 2: Deterministic domain view model

Files:

  • Create: apps/web/lib/projection-registry/view-model.ts
  • Test: apps/web/lib/projection-registry/view-model.test.ts

Interfaces:

  • Consumes: ProjectionManifest, ViewManifest.

  • Produces: buildDomainViewModel(projection, view) with metrics, rows/cards, signals, timeline, canvas blocks, and action labels.

  • Write failing tests for deterministic output, correct entity labels, stable metric values, and view-kind-specific surfaces.

  • Verify failing behavior.

  • Implement a deterministic preview model seeded from projection/view IDs and explicit manifest metadata.

  • Re-run view-model tests.

Task 3: Complete reusable domain shell

Files:

  • Create: apps/web/components/projections/domain-view-shell.tsx
  • Create: apps/web/components/projections/domain-surface.tsx
  • Create: apps/web/components/projections/execution-preview.tsx

Interfaces:

  • Consumes: completed ProjectionManifest, ViewManifest, buildDomainViewModel().

  • Produces: a responsive operational shell with View, Canvas, and Execution modes.

  • Implement accessible header, provenance, KPI strip, filters/actions, and non-persistent preview state.

  • Render differentiated table/board/dashboard/calendar/feed/canvas surfaces using existing shadcn primitives.

  • Add Signals/Attention panel and donor provenance.

  • Add Skills/Agents/Workflows execution preview with explicit Shell preview state and no external calls.

  • Verify mobile layout uses stacked panels and horizontal overflow only where required.

Task 4: Bind PR #127 routing to real shells

Files:

  • Modify: apps/web/app/(workspace)/[...view]/page.tsx

Interfaces:

  • Consumes: useDepartment(), completed projection registry, DomainViewShell.

  • Produces: actual domain shells at https://<projection>.spineworkspace.com/<view> instead of the current manifest-inspection placeholder.

  • Replace the metadata-card placeholder with DomainViewShell.

  • Preserve No Projection Context and View Not Found states.

  • Keep hostname-derived projection context authoritative.

Task 5: Donor coverage normalization

Files:

  • Modify: apps/web/lib/projection-registry/donor-catalog.ts
  • Test: apps/web/lib/projection-registry/completion.test.ts

Interfaces:

  • Consumes donor inventories from:

    • uploaded technical-accountsuccess-main.zip
    • uploaded account-success-main.zip
    • uploaded real_next.zip
    • integratewise/iw-spine-network-mcp L1 domain views
    • NirmalPrinceJ/Business_Intelligence
    • integratewise/org-mem.bookofprojects-integratewise

  • Produces canonical first-pass view inventories for all 18 projections.

  • Map Account Success, TAS, BI, Marketing, Campaigns, Sales, CS, RevOps, Finance, Operations, Product, Engineering, Support, Founder, Knowledge Management, Ops, Brandstore, and Book of Records.

  • Keep overlapping donor views once under the strongest canonical name.

  • Mark donor provenance for later Keep/Adapt/Merge/Retire migration work.

  • Ensure every projection has at least one dashboard/home view, operational entity views, an analytical view, and a canvas-capable view where appropriate.

Task 6: Verification

Files:

  • No new production files.

  • Run pnpm --filter my-v0-project test or the repository-equivalent apps/web Vitest command.

  • Run pnpm --filter my-v0-project typecheck.

  • Run pnpm --filter my-v0-project build.

  • Inspect PR checks and distinguish code failures from the repository's pre-existing blocked Vercel deployments.

  • Confirm no donor auth/Supabase imports were introduced into the new shell files.