simone
f7eb7eec23
.planning/ documentava in dettaglio cio che era vecchio e per niente cio
che e in produzione: le fasi 11-22 (v2.1 e v2.2, chiuse a giugno) erano
ancora in phases/ mentre v1.0 e v2.0 stavano gia in milestones/, e il
lavoro degli ultimi due mesi - gate OTP e ciclo di vita dei retainer, cioe
quello che gira su hub.iamcavalli.net - non aveva nessuna cartella.
- phases/{11,12,14} -> milestones/v2.1-phases/, phases/{18..22} ->
milestones/v2.2-phases/. Ora phases/ contiene solo la milestone in
corso, che e quello che state.cjs conta per il progresso
- v2.1-ROADMAP.md ricostruito: era l'unica milestone senza archivio,
interrotta dal reset del 19/06 e mai chiusa formalmente
- v2.3-ROADMAP.md + v2.3-REQUIREMENTS.md: v2.3 e stata eseguita fuori dal
ciclo GSD, non esistono PLAN/SUMMARY per fase. L'archivio E la doc
- REQUIREMENTS.md riscritto per v2.4 con il backlog reale
- phases/13 e phases/26: SUMMARY ricostruiti da commit, migration e
STATUS.md. 26 e il primo numero libero
- research/: cancellate 4 varianti dello stesso PITFALLS e FEATURES/
SUMMARY, superati da PROJECT.md. Diverse anti-feature erano ormai
contraddette dai fatti (il Kanban e stato costruito in Phase 19,
l'email in v2.3, il time tracking esiste)
- cancellati UI-RULES.md e DESIGN-SYSTEM.md (CLAUDE.md li dichiara
superseded: impongono l'inverso della regola attuale) e HANDOFF.md,
fermo al 13/06
- SECURITY-*.md -> security/: audit chiuso, ma i report restano la doc di
cosa e stato ruotato e perche
- PROJECT.md/MILESTONES.md/ROADMAP.md allineati: milestone corrente v2.4,
sessione OTP 90gg non 30, migrazioni fino alla 0016
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
44 lines
2.0 KiB
Markdown
44 lines
2.0 KiB
Markdown
---
|
||
phase: 12
|
||
plan: 02
|
||
type: execute
|
||
status: complete
|
||
wave: 2
|
||
completed: 2026-06-15
|
||
---
|
||
|
||
# 12-02 SUMMARY — Apply migration 0008 to production (BLOCKING checkpoint)
|
||
|
||
## What was done
|
||
|
||
Migration `0008_offer_tier_schema.sql` (created in Plan 01) was applied to the
|
||
**production** database via the idempotent push script, run from the local
|
||
environment through an operator-opened SSH tunnel (local `127.0.0.1:54321` →
|
||
production host Postgres `localhost:54321`).
|
||
|
||
Command used (credentials read from `.env.local`, host/port rewritten to the
|
||
tunnel endpoint via `URL()` — never printed):
|
||
|
||
```bash
|
||
DATABASE_URL=$(node --env-file=.env.local -e 'const u=new URL(process.env.DATABASE_URL); u.host="127.0.0.1:54321"; process.stdout.write(u.toString())') \
|
||
npx tsx scripts/push-12-offer-tier-schema.ts
|
||
```
|
||
|
||
Script output: all 14 statements reported `ready` — `✓ Migration 0008 (offer tier schema) applied successfully`.
|
||
|
||
## Verification (against live prod)
|
||
|
||
- `offer_macros` gained: `description, category, ticket, is_archived, cliente_ideale, risultato, tempo, pain, metodo` ✓
|
||
- `offer_micros` gained: `tier_letter`, `public_price` ✓
|
||
- Constraint `offer_micros_tier_letter_check` present ✓
|
||
- Table `offer_tier_services` exists with columns `tier_id, service_id, created_at` ✓
|
||
- Row counts unchanged (additive, no data loss): `offer_macros=1, offer_micros=1, clients=4, projects=5, payments=13, phases=6` ✓
|
||
|
||
## Issues Encountered
|
||
|
||
- First attempts failed: direct `178.104.27.55:54321` → `CONNECT_TIMEOUT` (firewalled, as in Phase 11); then through the tunnel `ECONNRESET` on all SSL variants. Root cause: the SSH `-L` forward initially targeted the wrong remote port; once re-opened pointing at the prod host's published Postgres port (`localhost:54321`), `SELECT 1` succeeded and the migration applied cleanly.
|
||
|
||
## Self-Check: PASSED
|
||
|
||
Migration 0008 is live on production; all new columns/constraint/table queryable; no destructive changes; Waves 3–4 schema-dependent code is now unblocked.
|