|
| 1 | +# Repository Layout Architecture Plan |
| 2 | + |
| 3 | +Status: Proposed |
| 4 | +Owner: Owner |
| 5 | +Scope: Documentation/governance only |
| 6 | + |
| 7 | +## Purpose |
| 8 | + |
| 9 | +Document the proposed repository architecture simplification before any file moves occur. |
| 10 | + |
| 11 | +This plan does not authorize moving files, changing runtime behavior, changing package commands, or mixing feature work into layout migration PRs. |
| 12 | + |
| 13 | +## Proposed Future Layout |
| 14 | + |
| 15 | +```text |
| 16 | +www/ |
| 17 | +api/ |
| 18 | +dev/ |
| 19 | +``` |
| 20 | + |
| 21 | +### www/ |
| 22 | + |
| 23 | +`www/` is the browser-served application. |
| 24 | + |
| 25 | +It will own deployable browser pages, browser assets, and static application entry points currently spread across root product folders, `assets/`, `docs/`, `games/`, `toolbox/`, and browser-facing runtime surfaces. |
| 26 | + |
| 27 | +`www/` must not own authoritative product data. |
| 28 | + |
| 29 | +### api/ |
| 30 | + |
| 31 | +`api/` is the Node/API/server application. |
| 32 | + |
| 33 | +It will own server entry points, API routing, API services, environment adapters, database access, storage access, server-side setup, and deployable API/runtime support code. |
| 34 | + |
| 35 | +`api/` owns the Browser -> API -> Postgres/R2 boundary. |
| 36 | + |
| 37 | +### dev/ |
| 38 | + |
| 39 | +`dev/` is the developer-only workspace. |
| 40 | + |
| 41 | +It owns Project Instructions, governance, architecture docs, reports, tests, scripts, templates, local developer bootstrap, generated output, zips, logs, and historical archive material. |
| 42 | + |
| 43 | +Production runtime, browser application code, and API deployment code must never depend on `dev/`. |
| 44 | + |
| 45 | +## Deployment Model |
| 46 | + |
| 47 | +The proposed target deployment model has two deployable application surfaces: |
| 48 | + |
| 49 | +- `www/` deploys the browser-served application. |
| 50 | +- `api/` deploys the Node/API/server application. |
| 51 | + |
| 52 | +`dev/` is not deployed as product runtime and must be excluded from runtime dependency paths. |
| 53 | + |
| 54 | +Environment differences remain governed by `.env` values and environment-managed secrets. The same deployable browser and API code paths must be promoted through Local, DEV, IST, UAT, and PROD. |
| 55 | + |
| 56 | +## Browser/API/Database Flow |
| 57 | + |
| 58 | +Required product-data flow: |
| 59 | + |
| 60 | +```text |
| 61 | +Browser -> API -> Postgres/R2 |
| 62 | +``` |
| 63 | + |
| 64 | +Rules: |
| 65 | + |
| 66 | +- Browser code reads and writes authoritative product data only through the API/service contract. |
| 67 | +- Product metadata is persisted in Postgres. |
| 68 | +- Product assets are persisted in Cloudflare R2. |
| 69 | +- Browser storage, page arrays, source JSON files, `/tmp`, and dev workspace files are not authoritative product-data sources. |
| 70 | +- Seed data is allowed only when it seeds the database through server/API/setup ownership. |
| 71 | + |
| 72 | +## Developer Local-Runtime Flow |
| 73 | + |
| 74 | +Local development may use the team-aware developer bootstrap and local runtime support, but the runtime boundary remains the same: |
| 75 | + |
| 76 | +```text |
| 77 | +Developer command -> dev bootstrap -> local www server + local api server -> Postgres/R2 or approved local provider |
| 78 | +``` |
| 79 | + |
| 80 | +Current local bootstrap commands remain unchanged by this plan. This PR does not modify `package.json` commands. |
| 81 | + |
| 82 | +The local developer workflow must continue to prove the same browser/API/database contract that deployed environments use. |
| 83 | + |
| 84 | +## Migration Strategy |
| 85 | + |
| 86 | +Migration must happen through small, reviewable, stacked PRs after this architecture plan is accepted. |
| 87 | + |
| 88 | +Rules: |
| 89 | + |
| 90 | +- No file moves occur in this plan PR. |
| 91 | +- No feature work may be mixed into migration PRs. |
| 92 | +- Each migration PR moves or rewires one bounded ownership area. |
| 93 | +- Each migration PR must preserve the same product behavior unless the PR is explicitly a behavior change. |
| 94 | +- Each migration PR must update references, validation, reports, and ZIP artifacts for only its scoped move. |
| 95 | +- Each migration PR must include rollback notes or clear validation evidence. |
| 96 | + |
| 97 | +## Proposed Stacked PR Sequence |
| 98 | + |
| 99 | +1. `www/` shell and governance |
| 100 | + - Create the destination shell and document browser-served ownership. |
| 101 | + - Do not move product pages yet. |
| 102 | + |
| 103 | +2. `api/` shell and governance |
| 104 | + - Create the destination shell and document API/server ownership. |
| 105 | + - Do not move API/runtime implementation yet. |
| 106 | + |
| 107 | +3. Browser-served public section moves |
| 108 | + - Move root browser-served product sections into `www/` in small groups. |
| 109 | + - Preserve routes through compatibility redirects or server/static configuration as needed. |
| 110 | + |
| 111 | +4. Browser asset moves |
| 112 | + - Move browser assets into `www/` ownership. |
| 113 | + - Preserve asset URLs or update references in the same PR. |
| 114 | + |
| 115 | +5. API/server moves |
| 116 | + - Move Node/API/server entry points and service code into `api/`. |
| 117 | + - Preserve API contract shape and route behavior. |
| 118 | + |
| 119 | +6. Runtime/shared source boundary cleanup |
| 120 | + - Move deployable browser/runtime/API modules into `www/` or `api/` ownership as appropriate. |
| 121 | + - Keep shared runtime dependency direction explicit. |
| 122 | + |
| 123 | +7. Developer bootstrap and validation updates |
| 124 | + - Update local developer bootstrap and validation paths after deployable surfaces are moved. |
| 125 | + - Keep `dev/` developer-only. |
| 126 | + |
| 127 | +8. Legacy path cleanup |
| 128 | + - Remove or archive obsolete empty folders and compatibility shims only after validation proves they are unused. |
| 129 | + |
| 130 | +## Hard Rules |
| 131 | + |
| 132 | +- No feature work may be mixed into repository layout migration. |
| 133 | +- Runtime must never depend on `dev/`. |
| 134 | +- Browser code must never own authoritative product data. |
| 135 | +- Browser code must use Browser -> API -> Postgres/R2 for product data. |
| 136 | +- API/server code must not import from developer-only reports, Project Instructions, tests, or workspace artifacts. |
| 137 | +- Migration PRs must not change package commands unless the PR explicitly owns command migration. |
| 138 | +- Migration PRs must not introduce Creator-writeable repository folders. |
| 139 | +- Migration PRs must not hide behavior changes inside path moves. |
| 140 | + |
| 141 | +## Validation Expectations |
| 142 | + |
| 143 | +Every layout migration PR must at minimum run: |
| 144 | + |
| 145 | +```text |
| 146 | +git diff --check |
| 147 | +npm run validate:canonical-structure |
| 148 | +``` |
| 149 | + |
| 150 | +Additional targeted validation must match the moved surface. |
| 151 | + |
0 commit comments