dtoro
18cb79caf9
- seeds/ontology.yaml: 59 entity types (5 abstract, is-a hierarchy), 46 relationship types with cardinality, 6 lifecycles with terminal states and named precondition checks - seeds/inventory.yaml: 110 entities / 142 relationships translated from legacy inventory.yaml (fleet, services, ingress, storage, governance, archaeology); thin spots marked for backfill - seeds/policy.yaml: 4 risk classes, 27 approval rules (hierarchy-aware, per-entity overrides), autonomy kill-switch off (cold start) - api/openapi.yaml: full v1 REST contract (40 paths), RFC 9457 errors, cursor pagination, idempotency, ETag/If-Match, scopes; redocly-clean - docs/adr/0001-0010: initial architecture decision records - scripts/validate-seeds.py: Phase 0 gate — hierarchy, lifecycles, endpoints, cardinality, policy cross-refs (0 errors) - plan: layer CHECK gains 'meta' (root type), cardinality gains 'many-to-one' Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
21 lines
893 B
Markdown
21 lines
893 B
Markdown
# ADR 0008 — Forward-only migrations
|
|
|
|
Status: accepted (2026-07-07) · Plan: rev 3 (resolves audit D5/O1)
|
|
|
|
## Context
|
|
Down-migrations are rarely tested and lie about reversibility once data
|
|
has flowed. Rollback needs a strategy that works with real data.
|
|
|
|
## Decision
|
|
golang-migrate, embedded (//go:embed), up-only. Migrations run in a
|
|
one-shot init container with a DDL-only DB user before app roles start.
|
|
Within one deploy window migrations are additive-only (new columns
|
|
nullable, new tables optional) so previous-SHA images tolerate the new
|
|
schema. Rollback = redeploy previous image tag; if the migration itself is
|
|
the problem, pg_restore the automatic pre-deploy dump. Mistakes roll
|
|
forward via compensating migrations.
|
|
|
|
## Consequences
|
|
- No down.sql to write or test; the pre-deploy dump is the real safety net.
|
|
- Destructive schema changes (drop/rename) take two deploys by design.
|