docs(confidence-engine): reconcile v0.48 persistence evidence
This commit is contained in:
+73
-40
@@ -1416,9 +1416,9 @@ The SAME existing investigation was reused throughout this experiment. No fresh
|
||||
|
||||
These counts are evidence from one particular live investigation, not permanent product expectations.
|
||||
|
||||
### PRIMARY UNRESOLVED ISSUE: Missing `focusedContributions[]` Persistence
|
||||
### CONTRADICTORY / UNREPRODUCED: Earlier `focusedContributions=[]` Observation
|
||||
|
||||
During the multi-turn cold-return experiment, canonical localStorage was observed with:
|
||||
During an earlier multi-turn cold-return experiment, canonical localStorage was observed with:
|
||||
|
||||
```
|
||||
focusedContributions: []
|
||||
@@ -1432,24 +1432,62 @@ contrib-0003
|
||||
contrib-0004
|
||||
```
|
||||
|
||||
**Therefore the persisted state observed at runtime contained durable Findings whose provenance pointed to Contribution records that were NOT present in the persisted `focusedContributions[]` array.**
|
||||
**Current status: THIS OBSERVATION WAS NOT REPRODUCED BY LATER EVIDENCE.**
|
||||
|
||||
This is structurally important. The distinction must be carefully preserved:
|
||||
A subsequent bounded runtime experiment (documented below) ran the identical investigation persistence path and did NOT reproduce `focusedContributions=[]`. The earlier observation is now **contradictory evidence**, not an active primary defect. Its cause remains **UNKNOWN** — it may have been conditional to the earlier runtime state, an inspection/timing issue, or another path not currently identified.
|
||||
|
||||
**PROVED:**
|
||||
- Canonical Findings persist correctly.
|
||||
- Their `contributionId` values persist correctly.
|
||||
- Canonical `focusedContributions[]` was observed empty during the multi-turn experiment.
|
||||
- Persisted Finding provenance references Contributions absent from that canonical array.
|
||||
**Important discipline:** Do NOT convert this observation into a new speculative defect (cold-hydration, schema migration, provider stripping, cold-start-only). The reproducing experiment began with four existing Contributions already recovered from canonical storage — materially weakening those hypotheses. Until the failure reproduces again under controlled conditions, it should NOT drive implementation work.
|
||||
|
||||
**NOT YET PROVED (unknown mechanisms):**
|
||||
- Why `focusedContributions[]` is empty.
|
||||
- Whether `appendFocusedContribution` fails to reach ScenarioForm state.
|
||||
- Whether ScenarioForm state contains Contributions but autosave writes stale state.
|
||||
- Whether another lifecycle/state transition clears the array.
|
||||
- Whether the issue is persistence, mutation timing, hydration, or another ownership boundary.
|
||||
---
|
||||
|
||||
**Do NOT write "Contributions are never persisted" as a settled root cause.** The live evidence proves the persisted canonical snapshot was missing them at the point of observation. The mechanism causing that is still unknown.
|
||||
### PROVEN: Stale Intermediate Explicit Save in `handleUpdate`
|
||||
|
||||
Source inspection proved a real but narrower issue:
|
||||
|
||||
During `handleUpdate`, an explicit `saveInvestigation()` can use the existing render-closure value of `focusedContributions` **before** the newly appended Contribution has committed.
|
||||
|
||||
**STALE INTERMEDIATE EXPLICIT SAVE = PROVED.**
|
||||
|
||||
However, `focusedContributions` is also a dependency of the canonical ScenarioForm autosave. The source path predicts that the later autosave should repair the stale intermediate write — and the latest bounded runtime experiment confirmed this prediction.
|
||||
|
||||
---
|
||||
|
||||
### LATEST BOUNDED RUNTIME EXPERIMENT — Contribution Persistence Proves Working
|
||||
|
||||
The same existing investigation was reused throughout. No fresh scenario was created. One natural focused turn was completed between cold-return checks.
|
||||
|
||||
**Before turn:**
|
||||
- `focusedContributions` = 4 (IDs: contrib-0001, contrib-0002, contrib-0003, contrib-0004)
|
||||
- findings = 11
|
||||
|
||||
**After the new turn:**
|
||||
- New Contribution: contrib-0005
|
||||
- New Findings: 3
|
||||
|
||||
**Canonical storage observations across timed settling checkpoints:**
|
||||
|
||||
| Time | focusedContributions | findings |
|
||||
|------|---------------------|----------|
|
||||
| T0 | 5 | 14 |
|
||||
| T+500ms | 5 | 14 |
|
||||
| T+2s | 5 | 14 |
|
||||
| T+5s | 5 | 14 |
|
||||
| T+10s | 5 | 14 |
|
||||
|
||||
**After page reload:**
|
||||
- `focusedContributions` = 5
|
||||
- findings = 14
|
||||
|
||||
Investigation recovered normally.
|
||||
|
||||
**Evidence proves:**
|
||||
- A newly completed Contribution reaches canonical persistence.
|
||||
- Canonical autosave persists it (reairs the stale intermediate explicit save).
|
||||
- It remains stable through timed settling.
|
||||
- Reload/hydration restores it.
|
||||
- The known stale explicit save does NOT explain the final durable state in this normal flow.
|
||||
|
||||
**No production fix is currently justified for Contribution persistence.** Do NOT pursue speculative cold-hydration/schema/provider fixes unless the `focusedContributions=[]` failure reproduces again.
|
||||
|
||||
### Previous Learning / History UI Observation (Evidence — Not Next Fix)
|
||||
|
||||
@@ -1470,38 +1508,33 @@ During the multi-turn experiment, incomplete historical presentation was also ob
|
||||
- Very long investigations have not been tested.
|
||||
- Multi-device/server persistence is not part of the current localStorage provider scope.
|
||||
|
||||
### NEXT PRIMARY TASK: Contribution Persistence Trace
|
||||
### NEXT BOUNDARY: Contribution Persistence Status Resolved
|
||||
|
||||
The next boundary for investigation is unmistakable:
|
||||
Contribution persistence no longer qualifies as the active primary defect. The latest bounded runtime experiment proved it works correctly in the observed normal flow (autosave repairs stale intermediate explicit saves; Contributions survive reload and settle stable).
|
||||
|
||||
**TRACE ONLY why canonical `focusedContributions[]` is empty in persisted localStorage during real multi-turn use even though Findings reference the corresponding `contributionId` values.**
|
||||
**Treat the earlier `focusedContributions=[]` observation as technical debt requiring reproduction before implementation work.** It is a known unexplained data point, not a justified engineering task.
|
||||
|
||||
Trace must follow actual runtime/source ownership:
|
||||
### Next Genuine Boundary (Post-Persistence Resolution)
|
||||
|
||||
```
|
||||
focused investigation response
|
||||
→ Contribution construction
|
||||
→ callback from ReasoningWorkspace
|
||||
→ ScenarioForm appendFocusedContribution
|
||||
→ setFocusedContributions
|
||||
→ React state
|
||||
→ canonical autosave effect
|
||||
→ saveInvestigation(snapshot)
|
||||
→ LocalStorageProvider
|
||||
→ stored focusedContributions[]
|
||||
```
|
||||
With Contribution persistence demonstrated working, the remaining unresolved boundaries from the handoff are:
|
||||
|
||||
Identify the FIRST boundary where the Contribution disappears. Do not assume the answer. The repository previously suggested:
|
||||
1. **Follow-up selected-question duplication** (OPEN UI ISSUE) — proposed follow-up appears simultaneously as ACTIVE QUESTION and STILL-AVAILABLE FOLLOW-UP; proposal state vs active-question state disconnect
|
||||
2. **Focused → global ownership/integration** (STILL OPEN) — how accumulated focused Findings map into the global SituationGraph reasoning layer
|
||||
3. **Current Understanding incorporating focused learning** (STILL OPEN) — narrative understanding should be reconstructed from globally eligible Findings + graph state, not directly from latest focused result
|
||||
|
||||
```
|
||||
ReasoningWorkspace → onFocusedContribution → ScenarioForm → focusedContributions state → autosave
|
||||
```
|
||||
**Selected next boundary: Focused → global Finding integration / Previous Learning presentation.**
|
||||
|
||||
but live browser evidence contradicts the expected persisted result. SOURCE ASSUMPTION vs LIVE RUNTIME EVIDENCE must now be reconciled. The browser evidence wins until the discrepancy is explained.
|
||||
**Why this is now the strongest next boundary:**
|
||||
- The Contribution persistence blocker that prevented assessing previous-learning completeness has been removed. If Contributions persist correctly to canonical storage and survive reload, then the Previous Learning panel should be able to render them without a persistence defect obscuring the UI question.
|
||||
- This is a product-semantic/user-facing progression (not internal cleanup). It directly tests whether the findings domain model established in the handoff can be exercised end-to-end: accumulated focused evidence → visible to user as usable context.
|
||||
- The previous-learning presentation observation was recorded specifically as "evidence, not the next implementation target" because persistence looked suspect. With that suspicion now resolved, the UI question becomes assessable on its own merits.
|
||||
|
||||
---
|
||||
|
||||
## Development Principles
|
||||
**What remains explicitly OUT OF SCOPE for this next boundary:**
|
||||
- Revisiting Contribution persistence (it is proven working)
|
||||
- The stale explicit save cleanup — a known technical debt item, but not a demonstrated user-visible failure in current flow
|
||||
- Follow-up selected-question duplication (separate UI issue; orthogonal to integration semantics)
|
||||
- Current Understanding narrative reconstruction (lower priority after integration is established)
|
||||
- Any speculative cold-hydration/schema/provider fixes
|
||||
|
||||
### BUILD → BREAK → LEARN
|
||||
|
||||
|
||||
Reference in New Issue
Block a user