julian
a8e808e71c
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.
43 lines
3.3 KiB
Markdown
43 lines
3.3 KiB
Markdown
# 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.
|
||
|
||
### GDPR / data retention
|
||
|
||
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.
|