Files

T

julian a8e808e71c Scaffold directus service planning structure

Initial commit. Establishes the .planning/ tree mirroring processor's
shape (ROADMAP.md as nav hub + per-phase folders with READMEs and
granular task files).

Six phases:

1. Slice 1 schema + deploy pipeline — what Rally Albania 2026 needs.
   Org catalog (orgs, users, vehicles, devices) + event participation
   (events, classes, entries, entry_crew, entry_devices). db-init/
   for the positions hypertable + faulty column. snapshot/apply
   tooling. Gitea CI dry-run. Dogfood seed of Rally Albania 2026.
   Nine task files with full Goal / Deliverables / Specification /
   Acceptance criteria / Risks / Done sections.

2. Course definition — stages, segments, geofences, waypoints, SLZs.
   PostGIS extension introduced here.

3. Timing & penalty tables — co-developed with processor Phase 2.
   entry_segment_starts, entry_crossings, entry_penalties,
   stage_results, penalty_formulas.

4. Permissions & policies — Directus 11 dynamic-filter Policies per
   logical role. Deployment-time work, deferred to keep early phases
   focused on the data model.

5. Custom extensions — TypeScript hooks/endpoints implementing the
   cross-plane workflows the schema implies (faulty-flag → Redis
   stream emit, stage-open materializer, etc.).

6. Future / optional — retroactivity preview UI, command-routing
   Flows, audit trails, federation rule import. Not committed.

Non-negotiable design rules captured in ROADMAP.md: schema authority
in Directus + snapshot-as-code + db-init for non-Directus DDL +
sequential idempotent migrations + entrypoint apply order + no
application logic in Flows + permissions deferred to Phase 4.

Architectural anchors point at the wiki at ../docs/wiki/ — the schema
draft, the Rally Albania 2025 source page, plus the existing
processor/postgres-timescaledb/live-channel pages. Each task file
calls out the wiki refs an implementing agent should read first.

README.md mirrors the processor service README structure: quick start,
local Docker test, prod/stage deployment notes, env vars, CI behavior.

2026-05-01 20:42:44 +02:00

3.3 KiB

Raw Blame History

Phase 6 — Future / optional

Status: ❄️ Not committed Outcome: Capability ideas that don't fit Phases 1–5 but are worth tracking so they don't get lost. Work here begins only when a concrete trigger arrives — usually a real event has surfaced a pain point Phases 1–5 don't address.

Ideas on radar

Retroactivity preview UI

Counterpart to processor Phase 2.5. When an operator edits a geofence or speed_limit_zone polygon with retroactive = true, before committing the change Directus shows a diff: "this edit will affect 47 entries, recompute will take ~12 minutes, here are the entries whose entry_penalties.seconds change." Implemented as a custom interface or pre-save modal driven by a server-side dry-run extension that calls into processor's replay engine.

Command-routing Flows for Phase 2 commands

Per wiki/concepts/phase-2-commands.md. Directus owns the commands collection. SPA inserts a row; a Directus Flow routes it via Redis to the tcp-ingestion instance holding the device's socket. Wait for ACK / nACK / timeout, update the row's status field, fire WebSocket subscription so the SPA learns the result. Substantial workstream, blocked on Phase 2 commands being ready in tcp-ingestion.

Audit trail extension

Out-of-the-box Directus tracks who changed what, but not in a way that's easy to surface to operators. A custom extension that materializes a per-entry timeline ("registered → confirmed → started → marshal flagged WP3 → race director recomputed penalties → published") would help during protests and post-event reviews. Pure read-side; consumes Directus's revisions/activity tables and presents them.

Federation rule import tooling

When the org publishes their Supplementary Regulation as a structured document (or even as a PDF that the operator transcribes), an import tool that creates penalty_formulas rows in bulk, validated against the evaluator registry. Saves the org from manually filling in 5–10 bracket rows per event. Could also export the seeded rules back to a human-readable document for review.

Multi-event leaderboard

Cross-event aggregation: "show me Aldo's results across all rallies he's run in the last 12 months." Requires either a materialized view or a custom endpoint that joins across events. Probably a SPA concern more than a Directus concern; mentioned here in case it's easier to build server-side.

Data export for federation submission

Many federations require post-event result submissions in specific CSV / XML formats. A custom endpoint that takes an event and a federation profile, emits the formatted file. Keeps formatting logic out of the SPA.

Participants have rights over their data; the system needs to support deletion-on-request, export-on-request, and configurable retention windows on positions data. Probably a Phase 4 (policies) + Phase 5 (extension) combo when actually needed; tracked here so we don't forget it.

When to promote one of these to a real phase

A real event surfaced a pain point this idea addresses.
A scheduled stakeholder commitment depends on it (federation sub-mission deadline, etc.).
The idea has been refined enough that the task breakdown is clear.

Until then: notes only. Don't pre-design.

3.3 KiB Raw Blame History Unescape Escape