Files
gupi-osint-board/docs/TODO.md
T

63 lines
4.2 KiB
Markdown

# GUPI OSINT Board roadmap
This is the ordered implementation roadmap following the accepted exhibit model. Work generally proceeds from top to bottom. It is not a substitute for migrations or implementation issues.
## Working agreement
- Spend roughly 60% of development time on features and model work, 25% on tests and bug fixing, and 15% on repository and deployment hygiene.
- Stop feature work for interaction-breaking, data-loss, migration, or deployment bugs. Batch cosmetic defects separately.
- A new exhibit behavior is complete only when its PostgreSQL representation, API behavior, frontend widget, persistence, and focused tests agree.
- Mystery content must be authored as template data through supported application operations, never hard-coded into React components.
## Milestone 0: trustworthy baseline
- [x] Track `.gitignore`, `.dockerignore`, and `.env.example`; confirm that secrets and generated artifacts cannot enter Git accidentally.
- [x] Commit the current working POC and tag the checkpoint `poc-pre-exhibit-model`.
- [x] Confirm `main` is pushed to the Ramanujan-hosted `origin` repository.
- [x] Keep `npm run build` green and make `npm test` run real tests rather than an empty suite.
## Milestone 1: focused safety net
- [x] Test screen/board coordinate conversion across pan and zoom levels.
- [x] Test timeline date-to-pixel projection and recomputation after viewport resizing.
- [ ] Test the interaction boundary between exhibit dragging, hand-tool panning, and board-only pinch zoom.
- [x] Test folder open/close behavior and retained file positions; add visual coverage for containment bands with the browser smoke test.
- [ ] Test document upload, metadata persistence, board save/reload, and reset.
- [x] Run migrations and API integration tests against disposable PostgreSQL, not SQLite or mocked persistence.
- [ ] Add one browser smoke test: open a level, drag an exhibit, zoom, open a folder, move a file, reload, and verify persistence.
## Milestone 2: exhibit-schema cutover
- [ ] Add boards, exhibits, exhibit types, subtype tables, immutable template versions, and cloned mutable levels.
- [ ] Migrate transitional `widgets`, `widget_relations`, and `playthrough_*` data with equivalence checks.
- [ ] Implement template instantiation and “save level as template” as transactional clone operations.
- [ ] Introduce a server-side repository/service boundary so SQL and cloning transactions do not live in Express route handlers.
- [ ] Move the frontend to an exhibit/widget registry backed by the normalized API.
- [ ] Remove transitional tables only after automated data-equivalence and behavior checks pass.
## Milestone 3: events and parties
### Events and narrative
- [ ] Implement Event exhibits with occurrence time and investigator-authored narrative text.
- [ ] Implement normalized Event-to-Evidence links and their board visualization.
- [ ] Present chronologically ordered events as the emerging investigation story.
### Party exhibits
- [ ] Add a Party exhibit supertype representing an investigation participant.
- [ ] Add a Person subtype with display name, normalized aliases, and extensible structured identity fields.
- [ ] Add an Organization subtype covering businesses, public bodies, associations, and informal groups.
- [ ] Add normalized many-to-many Party-to-Evidence associations with an optional explanatory note.
- [ ] Add typed Party-to-Party relationships such as employment, ownership, membership, control, and representation.
- [ ] Build distinct Person and Organization widgets that can open as dossiers and reveal associated evidence without using folder ownership semantics.
- [ ] Include parties, aliases, evidence associations, and party relationships in template/level cloning.
## Milestone 4: first playable mystery
- [ ] Design a small mystery that exercises documents, folders, notes, events, people, organizations, connections, and the timeline.
- [ ] Create it as an immutable level-template version using the same supported operations available to an author.
- [ ] Instantiate and solve a cloned level without modifying the template or relying on hard-coded case behavior.
- [ ] Turn the successful solve path into an end-to-end acceptance test.
- [ ] Perform a manual playability and visual-polish pass before production deployment.