T-B — Ingest & projector: FleetPulse ingest, pure presence projector, P12, heatmap on P06 #17

New issue

Open

opened 2026-09-11 09:02:11 +00:00 by bart · 0 comments

bart commented

2026-09-11 09:02:11 +00:00

Collaborator

Parent

Row T-B in docs/12-implementation-plan.md (branch, owned paths and doc section are defined there).

What to build

A FleetPulse document posted to the ingest endpoint is validated, hashed and idempotent, rejects unknown vehicles, honours site valid_from/valid_to, replaces presence blocks and suggests site suitability (S01, S02, S12, S16). A pure projector turns blocks into presence windows (DST, end_of_day, Q4 groups) through the worker. The ingest page P12 and the presence heatmap on P06 show the result.

Acceptance criteria

Posting the sample feed twice creates one ingest record and identical windows (idempotency integration test)
Unknown vehicle → rejected with the documented error code; sites outside validity are skipped per S12
Projector unit tests cover the DST week, a 24:00 block and grouped windows on the sample feed
P12 lists ingest records with status and errors; P06 heatmap renders windows for a vehicle
Projector imports only core and contracts; docs/03 §S01–S02 updated for any behaviour detail

Blocked by

#15 — API surface: every DTO and endpoint from docs/09-api.md stubbed, openapi.json committed
#14 — Seed: sample FleetPulse feed, catalogue, three crews, week of shifts, dev persons
#6 — Worker skeleton: claim loop, task handler registry, jobs discovery, heartbeat
#12 — Engine contracts: PlanningSnapshot, PlanResult, Finding, projector/scorer I/O, task payloads, code lists, fixtures
#13 — Web shared UI: Optimus wrappers, pipes, view-model types, generic admin CRUD, store slice pattern

## Parent Row **T-B** in `docs/12-implementation-plan.md` (branch, owned paths and doc section are defined there). ## What to build A FleetPulse document posted to the ingest endpoint is validated, hashed and idempotent, rejects unknown vehicles, honours site `valid_from`/`valid_to`, replaces presence blocks and suggests site suitability (S01, S02, S12, S16). A pure projector turns blocks into presence windows (DST, `end_of_day`, Q4 groups) through the worker. The ingest page P12 and the presence heatmap on P06 show the result. ## Acceptance criteria - [ ] Posting the sample feed twice creates one ingest record and identical windows (idempotency integration test) - [ ] Unknown vehicle → rejected with the documented error code; sites outside validity are skipped per S12 - [ ] Projector unit tests cover the DST week, a 24:00 block and grouped windows on the sample feed - [ ] P12 lists ingest records with status and errors; P06 heatmap renders windows for a vehicle - [ ] Projector imports only `core` and `contracts`; docs/03 §S01–S02 updated for any behaviour detail ## Blocked by - #15 — API surface: every DTO and endpoint from docs/09-api.md stubbed, openapi.json committed - #14 — Seed: sample FleetPulse feed, catalogue, three crews, week of shifts, dev persons - #6 — Worker skeleton: claim loop, task handler registry, jobs discovery, heartbeat - #12 — Engine contracts: PlanningSnapshot, PlanResult, Finding, projector/scorer I/O, task payloads, code lists, fixtures - #13 — Web shared UI: Optimus wrappers, pipes, view-model types, generic admin CRUD, store slice pattern

bart added the

ready-for-agent

label

2026-09-11 09:02:11 +00:00

bart added a new dependency

2026-09-11 09:02:24 +00:00

#15 PH1.7 — API surface: every DTO and endpoint from docs/09-api.md stubbed, openapi.json committed

bart added a new dependency

2026-09-11 09:02:24 +00:00

#14 PH1.6 — Seed: sample FleetPulse feed, catalogue, three crews, week of shifts, dev persons

bart added a new dependency

2026-09-11 09:02:24 +00:00