A real incident hit during directus Phase 1 task 1.5: 5 newly-created
collections were destroyed by a container rebuild because the baked-in
snapshot was stale. directus schema apply --yes enforces the snapshot
as the single source of truth — anything not in the snapshot gets
deleted.
This is correct for fresh-environment provisioning and prod, but
catastrophic during active schema development. Adding a callout to the
directus entity page so future readers see the operator rule alongside
the snapshot/apply pattern documentation:
Never restart or rebuild the Directus container while there are
uncommitted schema changes. Always: change → snapshot → commit →
rebuild/restart.
The recovery path (re-apply via MCP / admin UI, snapshot before
restart) is straightforward in dev but would be data-loss in prod.
Phase 3 hardening will introduce a DIRECTUS_SCHEMA_APPLY_MODE env var
with auto/dry-run/skip modes so dev environments default to
non-destructive behavior.
Substantial design artifact + canonical-source ingest for the TRM
business plane.
Schema draft (synthesis):
- wiki/synthesis/directus-schema-draft.md — working agreement for the
multi-tenant schema. Pseudo multi-tenant under organizations; entries
as the unit of timing; course definition (stages/segments/geofences/
waypoints/SLZs); penalty system "numbers in DB, math in code" with an
evaluator registry and progressive bracket math; per-entry timing
tables; per-stage start-order strategies (manual /
previous_stage_clean_result / inverse_top_n_then_natural /
inverse_of_overall) covering both Tirana 24h and Rally Albania
patterns. Two role surfaces (org role vs racing role) called out
explicitly. Decisions captured; Open questions reduced to one
(geometry retroactivity engine, deferred to Phase 2.5).
Source ingest:
- raw/Regulations_2025.pdf + wiki/sources/rally-albania-regulations-
2025.md — formal ingest of the canonical Rally Albania 2025
rulebook. Section numbers preserved as §X.Y so the schema draft and
future SPA work can cite precisely. Flagged follow-ups: the SLZ
formula lives in the Supplementary Regulations (don't hardcode);
M-7 numbering bug; unmodeled neutralization zones.
Faulty-position flag (cross-plane operator workflow):
- entities/postgres-timescaledb.md, entities/processor.md,
concepts/position-record.md — operator-controlled boolean on the
positions hypertable; processor filters WHERE faulty = false on
every read; flagging triggers windowed recompute via the
recompute:requests stream.
Implementation strategy on entity pages:
- entities/directus.md — Schema management section documenting the
snapshots/ + db-init/ convention, container-startup apply pipeline.
- entities/processor.md — Phase 2 long-lived branch model with
PROCESSOR_PHASE_2_ENABLED flag-gating for incremental main merges;
Phase 2.5 deferral note.
Index and log updated.
The wiki was silent on the actual stream name used by tcp-ingestion and
processor — anyone reading it to understand the architecture had no way
to find out what stream the services use. This gap contributed to a
stage-side bug where the two services' compiled defaults drifted
(tcp-ingestion: telemetry:teltonika, processor: telemetry:t), causing
~7 hours of silent zero-throughput before symptoms surfaced.
Changes:
- entities/redis-streams.md — added "Stream and key naming" table
covering the inbound telemetry stream, Phase 2 command streams, and
registry/heartbeat keys. Documented the telemetry:{vendor} convention
so a future Queclink/Concox adapter fits predictably.
- entities/processor.md — opening paragraph names the stream and
consumer group consumed.
- entities/tcp-ingestion.md — opening paragraph names the stream
produced; defers full naming convention to redis-streams.
- log.md — note entry recording the canonicalization and the stage
incident that triggered it.
Researched Directus's WebSocket subscription mechanism via context7 and
confirmed it only fires events for writes that go through Directus's
own ItemsService. Direct INSERTs from Processor are invisible to
subscribers. The previous claim in entities/directus.md that Directus
broadcasts Processor's writes was wrong.
New: wiki/concepts/live-channel-architecture.md captures the corrected
design with three options table, chosen-architecture diagram,
authorization flow, failure modes, multi-instance plumbing, scale
considerations, and open questions. Chosen path: Processor exposes its
own WebSocket endpoint for the high-volume telemetry firehose
(authentication via Directus-issued JWT, authorization delegated to
Directus once at subscribe time); Directus's built-in WebSocket covers
business-plane events. Each WebSocket serves the writes its plane
manages — preserves plane-separation and gives the gentlest failure
mode (Directus down only blocks new authorizations).
Updated:
- entities/directus.md — corrected the real-time-delivery section,
added pointer to the new concept page.
- entities/processor.md — added Live broadcast section in
responsibilities and a section explaining the dual-consumer-group
plumbing for multi-instance HA.
- index.md — listed the new concept.
- log.md — synthesis entry for 2026-05-01 documenting the correction.
julian