refactor: clarify investigation map as ux placeholder

This commit is contained in:
2026-08-05 10:20:28 +01:00
parent ce673b8eb4
commit 86d9bc3f48
4 changed files with 76 additions and 61 deletions
+24 -2
View File
@@ -99,10 +99,32 @@ temporary workaround and the desired eventual contract.
## Investigation Map (Workspace UX)
### Open design decision — final map shape intentionally unresolved
The current Investigation Map implementation exists **only** to validate:
- placement within the workspace;
- information density at preview scale;
- status presentation (established / current / unknown);
- responsive layout across viewports;
- interaction with surrounding components across turns.
It is NOT a committed design. The eventual map should be derived from the reasoning engine, not from hard-coded UI categories.
The following are unresolved design questions — do NOT treat them as agreed contract fields:
- Will the engine provide a flat topic list, hierarchy, branches, or grouped clusters?
- Who determines ordering — engine or user interaction?
- Will there be evidence counts, completion percentages, or path metadata?
- How does the map handle dynamic addition/removal of topics during investigation?
### Current entry (temporary)
| Feature | UI need | Temporary mock | Desired reasoning output | Likely stage | Notes |
| ---------------------- | ---------------------------------- | --------------------------------------------------- | -------------------------------------------------------------- | ---------------------- | -------------------------------------------------------- |
| InvestigationMap | Visible investigation progress | Mock topic set with manual turn-based status progression | Engine emits `investigationTopics: [{ title, status, ordering?, evidenceCount? }]` | Each turn — start and update response | UI displays topics in engine-determined order; statuses: "established" / "current" / "unknown" |
| InvestigationMap | Topic status evolution across turns | Hardcoded PROGRESSION array indexed by `investigationHistory.length` | Engine determines which topics are established, active, or unknown at each turn | Question selection phase | Topics should not expose graph internals; plain-language labels only |
| InvestigationMap | Visible investigation progress | **mock-only placeholder**: minimal set of neutral topic names (≤5) with manual turn-based status progression | Engine emits `investigationTopics: [{ title, status, ordering?, evidenceCount? }]` | Each turn — start and update response | UI displays topics in engine-determined order; statuses: "established" / "current" / "unknown" |
| InvestigationMap | Topic status evolution across turns | **mock-only placeholder**: Hardcoded PROGRESSION array indexed by `investigationHistory.length` | Engine determines which topics are established, active, or unknown at each turn | Question selection phase | Topics should not expose graph internals; plain-language labels only |
The current adapter (`lib/map/investigation-map-adapter.js`) uses generic placeholder names (e.g. "Starting point", "Current focus") explicitly because they do NOT represent a domain-specific design decision.
## Open Questions / Future Work