chore: establish pre-exhibit project baseline
This commit is contained in:
@@ -0,0 +1,6 @@
|
||||
node_modules
|
||||
dist
|
||||
data
|
||||
.git
|
||||
.env
|
||||
npm-debug.log
|
||||
@@ -0,0 +1,5 @@
|
||||
DATABASE_URL=postgres://osint:osint_secret@localhost:5433/osint_dev
|
||||
PORT=8787
|
||||
CORS_ORIGIN=http://localhost:5173
|
||||
LEVEL_EDITING_ENABLED=true
|
||||
MAX_DOCUMENT_BYTES=26214400
|
||||
@@ -0,0 +1,5 @@
|
||||
node_modules/
|
||||
dist/
|
||||
.env
|
||||
.DS_Store
|
||||
*.tsbuildinfo
|
||||
+43
-7
@@ -1,15 +1,49 @@
|
||||
# GUPI OSINT Board roadmap
|
||||
|
||||
This list tracks domain and product work that follows the accepted exhibit model. It is not a substitute for migrations or implementation issues.
|
||||
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.
|
||||
|
||||
## Exhibit-schema cutover
|
||||
## 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.
|
||||
- [ ] Keep `npm run build` green and make `npm test` run real tests rather than an empty suite.
|
||||
|
||||
## Milestone 1: focused safety net
|
||||
|
||||
- [ ] Test screen/board coordinate conversion across pan and zoom levels.
|
||||
- [ ] 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.
|
||||
- [ ] Test folder open/close behavior, retained file positions, and containment bands.
|
||||
- [ ] Test document upload, metadata persistence, board save/reload, and reset.
|
||||
- [ ] 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.
|
||||
|
||||
## Party exhibits
|
||||
## 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.
|
||||
@@ -19,8 +53,10 @@ This list tracks domain and product work that follows the accepted exhibit model
|
||||
- [ ] 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.
|
||||
|
||||
## Events and narrative
|
||||
## Milestone 4: first playable mystery
|
||||
|
||||
- [ ] 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.
|
||||
- [ ] 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.
|
||||
|
||||
Reference in New Issue
Block a user