ParkFlow receives canonical events from automated parking facilities, reconstructs vehicle journeys, and explains occupancy, queues, processing, equipment, faults, revenue, and data coverage—without ever controlling physical equipment.
Every developer owns a visible part of this shared acceptance journey.
Every student owns data/API behavior, a Hebrew interface, fixtures, tests, documentation, handoff, and a final demonstration. Every weekly task includes a copyable approval prompt.
Accounts, facility setup, event API, and file imports.
Open 64 weekly goals →TEAM 2 · J1–J4Reconstruction, search, timelines, and partial-session investigation.
Open 64 weekly goals →TEAM 3 · P1–P4Overview, occupancy, facility map, demand, and queues.
Open 64 weekly goals →TEAM 4 · R1–R4Processing, equipment, faults, revenue, quality, and reports.
Open 64 weekly goals →Sixteen calendar weeks provide approximately sixteen working days per developer. Scope stays small; ownership stays complete.
| Week | Theme | Expected shared evidence | Visible project result |
|---|---|---|---|
| W01 | Understand | Flow, terms, boundaries, inputs/outputs, one success and failure fixture. | Every developer can explain the owned feature before coding. |
| W02 | Contract | Minimum typed shapes, examples, errors, producer and consumer named. | Shared contracts stop sixteen features from drifting apart. |
| W03 | Prepare | Committed deterministic fixtures and initial tests. | Every owner can work before adjacent features exist. |
| W04 | First slice | Smallest visible or callable end-to-end path. | All sixteen features have a demonstrable beginning. |
| W05–06 | Build | Normal behavior, persistence, validation, and user path. | The primary upload-to-analysis journey takes shape. |
| W07–08 | Failure states & test | Partial, invalid, duplicate, empty, unavailable, RTL, keyboard, and contract tests. | Missing telemetry degrades honestly instead of breaking the product. |
| W09–10 | Connect | One upstream and one downstream typed integration test. | Features join without shared-table coupling or duplicated formulas. |
| W11–12 | Complete & safe | Final journey, access, privacy, read-only boundary, and accessibility. | The complete owner and manager scenarios work safely. |
| W13–14 | Stabilize & polish | Thirty-day fixture, measured behavior, approved design, and Hebrew copy. | The integrated desktop product becomes review-ready. |
| W15–16 | Handoff & demonstrate | Runbook, known limits, owned evidence, and individual live demonstration. | Each student can explain exactly what she or he built. |
The DE-63-inspired fixture is one implementation example; the model remains flexible enough for robots, elevators, and other systems.
The licence plate identifies the vehicle. The source system checks restrictions, chooses a compatible location, and directs the driver to a floor and zone.
The gate opens, the driver parks on the prepared platform, confirms completion, and the automated mechanism stores the vehicle.
The user enters an identifier at a lobby kiosk. Simultaneous requests form a queue while equipment prepares vehicles.
The system reports the collection location, the vehicle becomes ready, and the exit event closes the journey when available.
Students collaborate only on the contract, fixtures, one integration test, and necessary integration fixes.
CanonicalEvent {
eventId, facilityId, eventType, occurredAt,
licencePlate?, externalSessionId?,
location?: { levelId?, zoneId?, spaceId? },
equipment?: { equipmentId?, type? },
requestId?, movementId?, vehicle?, pricing?,
fault?, sourceSystem?, metadata?
}
Required for every event:
eventId + facilityId + eventType + occurredAt
Vehicle events additionally require licencePlate.ParkingSession {
internalSessionId, externalSessionId?, licencePlate,
status, completeness, events[], issues[],
arrivalAt?, storedAt?, retrievalRequestedAt?,
readyAt?, exitedAt?, levelId?, zoneId?, spaceId?
}
DataIssue {
type, sessionId?, eventIds[], missingRequirements[],
candidates[], affectedMetrics[], explanation
}Facility {
id, name, levels[], accessPoints[], equipment[]
}
Level { id, facilityId, zones[] }
Zone { id, levelId, spaces[] }
Space {
id, zoneId, usable,
maxWidth?, maxHeight?, maxWeight?
}
Equipment {
id, facilityId, type, location?, label
}MetricResult<T> {
value?: T, availability,
numerator?, denominator?, sampleSize?,
coveragePercent, requiredEvents[],
missingRequirements[], range, comparison?,
methodologyVersion
}
Never encode unavailable as zero.
Never describe time overlap as causation.Reviewed ParkFlow shell, tables, charts, timelines, map, forms, coverage labels, and failure states.
Validated routes, authorization, ingestion, domain services, analytical reads, health, and structured logs.
Seeded roles, migrations, facility/event/session records, and server-enforced scoping.
Three levels, zones A–F, ninety spaces, thirty days, partial data, faults, pricing, and duplicates.
| Team | Owned records | Cross-team access |
|---|---|---|
| Data & Setup | Users/roles, facility hierarchy, equipment definitions, ingestion runs, immutable canonical events. | Exposes typed auth, facility, validation, and event services. |
| Parking Journeys | Internal sessions, associations, unmatched events, session issues, journey read models. | Consumes accepted events; exposes session and issue views. |
| Facility Performance | Owned analytical queries/read models for overview, occupancy, map, demand, and queues. | Consumes typed session/facility views; never rewrites source evidence. |
| Business & Reliability | Duration, equipment, fault, revenue, quality, and report read models. | Consumes typed summaries and evidence; never recalculates another owner's metric differently. |
The main journey plus boundary cases prove the system is coherent and honest.