Clean-repo migration
Why we are starting in a new repo, and how files move over one page/workflow slice at a time without carrying drift.
Clean-repo migration
Decision
Progress in E:\writing-system is blocked by accumulated history and drift. The new work moves into E:\blockdata piece by piece instead of forking the whole repo.
The migration is outside-in:
- Start with only the public non-auth landing pages already started in
E:\blockdata. - Move auth-entry and auth-gated pages one page/workflow at a time.
- For each page, bring only the backend pieces that page actually needs.
- Get each slice live before moving the next slice.
Current First Wave
The active first wave is the three public landing pages already present in E:\blockdata:
| Target repo file | Role |
|---|---|
apps/web/public/index.html | main public landing page |
apps/web/public/solutions.html | public solutions page |
apps/web/public/brand.html | public brand/product page |
Login, register, auth callback, welcome, app shell, and auth-gated product pages are not part of this first wave.
Working Unit
The working unit is:
page/workflow
-> required frontend components
-> required API/backend contract
-> required data/secrets/deploy config
-> live verificationFor each auth-gated page, bring only the backend pieces that page actually needs:
- auth/session handling
- API endpoints
- models
- DB tables/migrations
- secrets/env
- storage
- service adapters
If a page requires API work, stand up that API slice in the new dev environment for that page. Do not wait for a large backend migration.
Data Rule
Postgres is redesigned cleanly in Neon as each page slice needs it.
- One page may get one table.
- A workflow may get a small group of tables if it truly requires them.
- Existing SQL files in
E:\writing-systemcan be referenced. - Existing SQL/migration files are never copied over as migration history.
- The old migration chain is drifted and must not become the new repo's history.
Non-Goals
Do not copy unrelated pages, unrelated backend modules, old drift, or whole subsystems just because they exist in E:\writing-system.
Related Pages
- Decisions is the living decision ledger.
- Cloudflare stack proposal is a proposal, not a confirmed implementation record.
- Where to start and Non-auth inventory are dependency research pages. Their old route-level inventories are reference material, not the current first-wave move order.