ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
03b1beb616
TenantAtlas/specs/183-website-workspace-foundation/data-model.md
ahmido 03b1beb616 feat: implement workspace foundation website app (#214) 
## Summary
- add the first multi-app workspace foundation with a new standalone Astro website under `apps/website`
- introduce repo-root pnpm workspace orchestration and migrate the platform Node workflow from npm assumptions to pnpm
- update root docs, editor or agent guidance, and workspace-focused smoke tests for the new platform plus website command model
- add Spec 183 artifacts for spec, plan, research, contracts, quickstart, checklist, and tasks

## Verification
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/WorkspaceFoundation`
- `cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`
- `corepack pnpm build:website`
- integrated-browser smoke: verified `http://localhost/up`, `http://localhost/admin/login`, and `http://localhost:4321/` including website anchor navigation and combined root dev flow

## Notes
- branch: `183-website-workspace-foundation`
- commit: `6d41618d`
- root command model now covers `dev:platform`, `dev:website`, `dev`, `build:platform`, and `build:website`
- website port override documentation is included in the command contract, quickstart, and README

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #214
2026-04-08 12:20:31 +00:00

5.2 KiB
Raw Blame History

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