Phase 2 — Introduce V4 Products/Systems data model

[b5463]

Part of Milestone B — V4 Operational Core. Ref: #27

Create the V4 domain model while keeping current projects alive. This is the real foundation of V4 — if this is wrong, everything later becomes painful.

---

Alex tasks

New tables

• products
• systems
• system_environments
• releases
• domains
• environment_secrets
• infrastructure_metrics
• health_snapshots
• legacy_project_map

Migration bridge

• Map projects → legacy_project_map → systems → production environment → current release → default domain
• Field mapping: name, slug, deploy_type, status, repo, deploy_branch, is_primary, visibility, health_path, route_published, basic_user/hash, container_id, image_id, port, previous_*

Read APIs (first)

• GET /api/systems
• GET /api/systems/:id
• GET /api/systems/:id/environments
• GET /api/systems/:id/releases
• GET /api/products
• GET /api/products/:id

Write APIs (after read APIs are stable)

• POST /api/systems
• PATCH /api/systems/:id
• POST /api/products
• PATCH /api/products/:id

Legacy compatibility

• GET /api/projects reads from V4 tables when ENABLE_V4_SYSTEMS=true
• GET /api/projects/:slug same

Tests

• Project-to-system migration test
• Legacy projects API still works
• Systems API returns migrated projects
• One project becomes one system with production environment
• deploy_history maps to releases correctly
• Health/stats map correctly
• route_published maps correctly

---

Tomas tasks

• Dashboard Systems page displays V4-backed systems through same visual layout (no redesign — just source swap)
• Hidden admin/test Product page for early validation

---

Do not build yet

Multiple environments UI, promote preview, portfolio CMS, commerce, licensing.

Exit gate

• All current projects visible as systems
• Legacy project API still works
• Current deploy flow still works
• No route files changed by migration alone
• Backup/restore includes V4 tables

Rollback

Keep projects table as source of truth. Disable ENABLE_V4_SYSTEMS.