# Data Model: Website / Workspace Foundation

This feature does not introduce database entities. The relevant model is the set of repository-owned artifacts and runtime boundaries that define how the multi-app workspace behaves.

## 1. RootWorkspace

**Purpose**: The canonical repo-level contract for JavaScript workspace orchestration and contributor entry paths.

**Backed by**:
- Root `package.json`
- Root `pnpm-workspace.yaml`
- Root lockfile (`pnpm-lock.yaml`)
- Root README and root tooling guidance

**Key fields / responsibilities**:
- Official package-manager declaration
- Workspace package globs (`apps/*`)
- Official root scripts for platform start, website start, parallel dev, website build, and platform frontend build
- Documentation of the root-versus-app ownership model

**Validation rules**:
- Must include `apps/platform` and `apps/website` as workspace applications
- Must not claim ownership of app-local runtime logic
- Must not introduce `packages/` or additional app surfaces in this slice

## 2. PlatformApp

**Purpose**: The existing TenantPilot Laravel runtime under `apps/platform`.

**Backed by**:
- `apps/platform/composer.json`
- `apps/platform/package.json`
- `apps/platform/artisan`
- `apps/platform/bootstrap/`
- `apps/platform/public/`
- `apps/platform/resources/`
- `apps/platform/tests/`
- Existing Sail/Compose integration via `./scripts/platform-sail`

**Key fields / responsibilities**:
- Laravel application runtime and PHP dependency management
- Filament admin/system/tenant panels
- Platform frontend assets and Vite configuration
- Platform test surface and deployment-time asset publishing

**Validation rules**:
- Must remain functional under the new root workspace model
- Must stay on Filament v5 with Livewire v4
- Provider registration remains in `apps/platform/bootstrap/providers.php`
- Platform assets remain isolated under platform-owned paths

## 3. WebsiteApp

**Purpose**: The new standalone public website application under `apps/website`.

**Backed by**:
- `apps/website/package.json`
- `apps/website/astro.config.mjs`
- `apps/website/src/`
- `apps/website/public/`
- Website build output directory (implementation-specific, app-local)

**Key fields / responsibilities**:
- Public-facing pages and layouts
- Static-first dev/build lifecycle
- Website-owned public assets
- No shared auth/session/runtime assumptions with the platform app

**Validation rules**:
- Must run independently from the platform app
- Must not depend on Blade, Filament, or Laravel sessions
- Must not write into platform build-output directories

## 4. OfficialCommandModel

**Purpose**: The documented contract that tells contributors how to work from the repo root and from app-local directories.

**Backed by**:
- Root `package.json` scripts
- README command documentation
- VS Code task entry points where relevant

**Key fields / responsibilities**:
- Root install flow for JavaScript workspace dependencies
- Root platform start command
- Root website start command
- Root combined parallel-dev command
- Root website build command
- Root platform frontend build command
- App-local equivalents for `apps/platform` and `apps/website`

**Validation rules**:
- Root commands orchestrate only and delegate to app-local logic
- App-local commands remain valid and documented
- No second undocumented “official” workflow is introduced

## 5. ToolingSurface

**Purpose**: Root-level automation and editor guidance that must understand the multi-app repo shape.

**Backed by**:
- `README.md`
- `Agents.md`
- `GEMINI.md`
- `.github/copilot-instructions.md`
- `.vscode/tasks.json`
- `.vscode/mcp.json`
- `opencode.json`

**Key fields / responsibilities**:
- Explain root entry model and app ownership
- Keep Boost MCP explicitly scoped to the platform app
- Provide official entry tasks or labels for platform, website, and parallel dev

**Validation rules**:
- Tooling must not imply the website is a second Laravel app
- Tooling must not hide the official root entry path
- Platform-specific commands must remain clearly labeled as platform-specific

## 6. BuildBoundary

**Purpose**: The isolation contract between platform assets and website assets.

**Backed by**:
- Platform Vite output paths
- Website build output paths
- Ignore files and docs

**Key fields / responsibilities**:
- Platform frontend artifacts remain under `apps/platform`
- Website build artifacts remain under `apps/website`
- Root build commands invoke app-local builds without cross-writing outputs

**Validation rules**:
- Building the website must not overwrite or depend on platform artifacts
- Building platform frontend assets must not overwrite or depend on website artifacts
- Ignore files must cover both apps' dependency and build outputs

## Relationships

- `RootWorkspace` orchestrates `PlatformApp` and `WebsiteApp`.
- `OfficialCommandModel` is owned by `RootWorkspace` and delegates into `PlatformApp` and `WebsiteApp`.
- `ToolingSurface` documents and automates `OfficialCommandModel`.
- `BuildBoundary` constrains both `PlatformApp` and `WebsiteApp`.

## Out-of-scope Entities

The following are explicitly not introduced in this feature:

- Shared packages under `packages/`
- A docs application
- A customer or auditor application
- Shared auth/session infrastructure
- New database entities or runtime-persisted domain truth