updated context documents
This commit is contained in:
@@ -72,3 +72,21 @@ Previous cases may suggest where to investigate, but they must never determine
|
||||
the outcome of a new case.
|
||||
|
||||
Every case begins with no accepted evidence from previous cases.
|
||||
|
||||
## Product Principle: TL;DR First
|
||||
|
||||
The Confidence Workspace is not a document viewer or chat transcript. It is an active investigation workspace.
|
||||
|
||||
At any point, the interface should allow a user returning after seconds, minutes or hours to understand where they are within a few seconds.
|
||||
|
||||
The workspace should always answer:
|
||||
|
||||
1. What is the situation?
|
||||
2. What have we established?
|
||||
3. What is the single most important thing to determine next?
|
||||
4. Why does that matter?
|
||||
5. How close are we to having sufficient confidence?
|
||||
|
||||
The interface should minimise cognitive load by presenting the current state first and allowing progressively deeper exploration only when requested.
|
||||
|
||||
The engine may contain hundreds of reasoning nodes; the user should only see the information required to take the next meaningful action.
|
||||
|
||||
@@ -135,3 +135,45 @@ Avoid:
|
||||
- dashboard-style density.
|
||||
|
||||
The next question should be the strongest visual element.
|
||||
|
||||
## TL;DR Workspace Rules
|
||||
|
||||
The newest state is the most important state.
|
||||
|
||||
The primary focus of every screen should be the user's next action, not the history of how they arrived there.
|
||||
|
||||
### Information hierarchy
|
||||
|
||||
1. Current investigation
|
||||
2. Why this matters
|
||||
3. Response
|
||||
4. Current understanding
|
||||
5. Investigation history
|
||||
6. Original situation
|
||||
7. Developer details
|
||||
|
||||
### Progressive disclosure
|
||||
|
||||
Show only the information needed for the current decision.
|
||||
|
||||
Everything else should be collapsible or secondary.
|
||||
|
||||
### Cognitive load
|
||||
|
||||
The user should never need to scan an entire page to discover:
|
||||
|
||||
- what is happening
|
||||
- what they need to do next
|
||||
- why they are being asked
|
||||
|
||||
These should always be immediately visible.
|
||||
|
||||
### Investigation history
|
||||
|
||||
History exists to provide confidence and traceability, not to compete with the current investigation.
|
||||
|
||||
History should remain collapsed unless the user chooses to inspect previous reasoning.
|
||||
|
||||
### Original situation
|
||||
|
||||
Once an investigation has started, the original scenario becomes reference material rather than the primary focus.
|
||||
|
||||
@@ -121,3 +121,5 @@ At the end of a task, normally report only:
|
||||
Stop after reporting. Do not begin the next task automatically.
|
||||
|
||||
When a task is interrupted by output limits, resume with a narrowly scoped repair prompt rather than restating the entire original brief.
|
||||
|
||||
User interfaces communicate reasoning, not implementation. If a piece of information exists only because the engine tracks it internally (graph nodes, unresolved counts, edge totals, confidence scores), it should remain in Developer Details unless it directly helps the user make their next decision.
|
||||
|
||||
Reference in New Issue
Block a user