docs(runtime): close checkpoint and primitive follow-through

This commit is contained in:
Saravana Achu Mac 2026-04-04 12:15:40 -07:00
parent 9aeb9bbd59
commit 41673125af
5 changed files with 24 additions and 29 deletions

View File

@ -357,15 +357,13 @@ Current state:
- sessions, tasks, runs, approvals, actions, and dispatch validation are already exposed through - sessions, tasks, runs, approvals, actions, and dispatch validation are already exposed through
`cowork-service` `cowork-service`
- todos are currently task-backed - todos and checkpoint summaries now come from persisted Cowork checkpoint records
- replay anchors now use canonical Rust audit `event_id` - replay anchors now use canonical Rust audit `event_id`
Next conforming steps: Next conforming steps:
1. add a first-class Cowork todo/checklist source or make the task-backed mapping an explicit long-term choice 1. preserve canonical event IDs anywhere approval/audit state crosses service boundaries
2. expose checkpoint metadata or equivalent persisted resume summaries through product-facing runtime surfaces 2. document which Cowork transitions are direct observations versus projections derived by `cowork-service`
3. preserve canonical event IDs anywhere approval/audit state crosses service boundaries
4. document which Cowork transitions are direct observations versus projections derived by `cowork-service`
Conformance bar: Conformance bar:
@ -392,15 +390,13 @@ Required external contract surface:
Current state: Current state:
- sessions, tasks, todos, runs, approvals, actions, and dispatch validation are exposed through the backend - sessions, tasks, todos, runs, approvals, actions, and dispatch validation are exposed through the backend
- approvals are derived from agent-suggested schedule entries - approvals, todos, and checkpoints are now persisted as native runtime records in FlowMonk
- todos are derived from the planning backlog - run/session rollover rule: one planning workspace session exists per user, and each schedule entry becomes a new run inside that session
Next conforming steps: Next conforming steps:
1. decide whether approvals remain derived or become a first-class product primitive 1. decide whether approvals and todos will eventually gain direct end-user editing surfaces or remain runtime-managed records
2. decide whether backlog tasks are the permanent todo model or whether a distinct checklist model will exist 2. preserve richer artifact and memory refs in checkpoint summaries once downstream runtime producers are connected
3. expose checkpoint summaries for planning sessions so resume state is not inferred only from final records
4. document the exact rule for when a scheduled entry becomes a new run under an existing session
Conformance bar: Conformance bar:

View File

@ -270,10 +270,8 @@ These should be resolved before claiming the ecosystem docs are fully implementa
### 6.1 Remaining Direct Runtime TODOs ### 6.1 Remaining Direct Runtime TODOs
- Cowork: add `AgentTodo` direct projection once the product exposes first-class todo entities. - Cowork: enrich checkpoint summaries with artifact and memory refs when those runtime links are available.
- FlowMonk: replace the current derived approval/todo projections once the product exposes first-class approval/todo primitives. - FlowMonk: decide whether runtime approvals and todos should gain direct user-managed editing surfaces or remain runtime-managed records.
- Cowork: expose product-facing checkpoint summaries for resume review.
- FlowMonk: expose product-facing checkpoint summaries and document the run/session rollover rule.
### 6.2 Explicit Blockers And Questions ### 6.2 Explicit Blockers And Questions

View File

@ -107,16 +107,17 @@ Observed baseline:
- `a57b367` cowork-service runtime projections now prefer canonical audit event IDs - `a57b367` cowork-service runtime projections now prefer canonical audit event IDs
- `97b731e` cowork-service runtime todo projection - `97b731e` cowork-service runtime todo projection
- `faf93ec` FlowMonk approval and todo projections - `faf93ec` FlowMonk approval and todo projections
- `34c9b78` Cowork persisted checkpoint IPC surface
- `9aeb9bb` shared checkpoint schema plus cowork-service checkpoint and todo review routes
- `86470b2` FlowMonk native runtime todo, approval, and checkpoint persistence
## 7. Remaining Gaps ## 7. Remaining Gaps
- Cowork now emits shared runtime projections from cowork-service, preserves Rust-side canonical event IDs on approval/audit records, and still lacks a first-class native `AgentTodo` product source behind the current task-backed projection. - Cowork now emits shared runtime projections from cowork-service, preserves Rust-side canonical event IDs on approval/audit records, and exposes persisted checkpoint-driven todo and resume review surfaces.
- FlowMonk now emits direct runtime projections for planning sessions, tasks, todos, runs, approvals, and action logs, but it still lacks distinct native checklist and approval entities behind those projections. - FlowMonk now emits direct runtime projections for planning sessions, tasks, todos, runs, approvals, actions, and checkpoints with persisted native runtime records.
- the conforming implementation plan is now explicit in the runtime contract, but the product-level follow-through still remains: - remaining follow-through is now evolutionary rather than blocking:
- Cowork needs a first-class todo source or an explicit decision to keep the task-backed mapping - Cowork can later expose richer checkpoint artifact and memory refs
- Cowork needs product-facing checkpoint summaries - FlowMonk can later add direct user-managed editing surfaces for runtime approvals and todos if desired
- FlowMonk needs an explicit decision on whether approvals/todos stay derived or become first-class primitives
- FlowMonk needs product-facing checkpoint summaries and a documented run/session rollover rule
## 8. Explicit Blockers And Questions ## 8. Explicit Blockers And Questions

View File

@ -43,13 +43,11 @@ Current runtime adoption state:
- shared runtime projections now exist through `cowork-service` - shared runtime projections now exist through `cowork-service`
- audit/action surfaces preserve canonical Rust `event_id` - audit/action surfaces preserve canonical Rust `event_id`
- approvals and action logs can participate in ActionTrail replay - approvals and action logs can participate in ActionTrail replay
- todos are still derived from orchestrator tasks - persisted checkpoint records now back runtime todo review and runtime checkpoint summaries
Remaining follow-up: Remaining follow-up:
- add an explicit product-local helper for exporting ecosystem-ready audit payloads - add an explicit product-local helper for exporting ecosystem-ready audit payloads
- decide whether task-backed todo projection is temporary or permanent
- expose product-facing checkpoint summaries for resume review
- optionally emit canonical runtime events alongside the current local audit logs - optionally emit canonical runtime events alongside the current local audit logs
- add signed dispatch or upload flow from Cowork desktop into ActionTrail when runtime integration is prioritized - add signed dispatch or upload flow from Cowork desktop into ActionTrail when runtime integration is prioritized
@ -58,3 +56,4 @@ Remaining follow-up:
## 4. Commits ## 4. Commits
- existing producer surface predates Phase 3 baseline - existing producer surface predates Phase 3 baseline
- `34c9b78` added persisted checkpoint IPC summaries for runtime todo and resume review

View File

@ -20,13 +20,14 @@
- [x] include correlation/session IDs for downstream linking - [x] include correlation/session IDs for downstream linking
- [x] persist latest plan indexes for downstream consumers - [x] persist latest plan indexes for downstream consumers
- [x] expose direct runtime sessions, tasks, todos, runs, approvals, and actions - [x] expose direct runtime sessions, tasks, todos, runs, approvals, and actions
- [ ] decide whether approvals remain derived or become first-class primitives - [x] persist native runtime todos, approvals, and checkpoints
- [ ] decide whether todos remain backlog-task projections or become a first-class checklist primitive - [x] expose product-facing checkpoint summaries for planning-session resume
- [ ] expose product-facing checkpoint summaries for planning-session resume - [x] document the rule for when a scheduled entry becomes a new run under an existing session
- [ ] document the rule for when a scheduled entry becomes a new run under an existing session - [ ] decide whether runtime approvals and todos need direct user-managed editing surfaces
Commits: Commits:
- `59ab8b1` implemented the Phase 2 producer path - `59ab8b1` implemented the Phase 2 producer path
- `1ccafa7` implemented direct runtime sessions, tasks, runs, actions, and dispatch validation - `1ccafa7` implemented direct runtime sessions, tasks, runs, actions, and dispatch validation
- `faf93ec` implemented direct runtime approvals and todos - `faf93ec` implemented direct runtime approvals and todos
- `86470b2` persisted native runtime todo, approval, and checkpoint records