julian
f9b96efc6b
trm/directus Phase 1 image is on the registry; trm/deploy's compose.yaml has been extended with a directus service block that shares the existing postgres service with processor (different tables, no contention). Bringing the architecture wiki up to date. wiki/entities/directus.md updates: - New "Deployment" section: links to the deploy compose, names the shared-Postgres model with processor, spells out the 5-step boot pipeline (db-init pre-schema → bootstrap → schema apply → db-init post-schema → start), notes first-boot (~60-90 s) vs warm-boot (~10 s) timing, points at deploy/README.md's first-deploy checklist. - New "Network exposure" subsection: directus is internal-only on stage / prod (expose: 8055 not ports:). A reverse proxy on the host or attached to trm_default terminates TLS and forwards the public domain to http://directus:8055. The asymmetry with tcp-ingestion (which must host-publish for GPS devices) is named. The dev compose's deliberate divergence (host-publishes 8055 for local iteration) is noted. - Schema management section: db-init split into pre-schema (db-init/) and post-schema (db-init-post/) phases. Post-schema landed because the composite UNIQUE constraints target Directus-managed tables that don't exist until schema apply runs. Both phases run via the same apply-db-init.sh with DB_INIT_DIR overridden between calls. - Destructive-apply hazard callout: corrected entrypoint step reference (now step 3/5, not 2/4) after the bootstrap-before-apply reorder that landed during CI iterations. log.md entry records the three CI iterations that surfaced three distinct production-breaking bugs (port collision; ordering + silent ERROR exit; ghost-collection apply conflict) — all caught by the dry-run gate before reaching stage. Ghost-collection stripping is now automated in scripts/schema-snapshot.sh so future captures don't regress.
The file is empty.