Files

T

simone f7eb7eec23 docs(planning): archivia v2.1/v2.2/v2.3 e documenta v2.4

.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>

2026-08-08 22:38:36 +02:00

2.0 KiB

Raw Blame History

phase, plan, type, status, wave, completed

phase	plan	type	status	wave	completed
12	02	execute	complete	2	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):

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.

2.0 KiB Raw Blame History Unescape Escape