# Optional Product Enhancement Backlog

> **Status:** Active backlog
> **Owner:** `learning_ai_common_plat`
> **Purpose:** Track post-baseline ecosystem enhancements that are useful, but not required for the Phase 1 to Phase 5 roadmap baseline.

---

## 1. Why This Exists

The core ecosystem roadmap is now materially complete through Phase 5.

What remains is not baseline contract or integration work. It is product-deepening work that should be prioritized only when the expected user value justifies the extra complexity.

This backlog keeps those items visible without mixing them back into the completed roadmap baseline.

---

## 2. Backlog Items

### 2.1 FlowMonk richer replay execution controls

> **Status:** implemented

> **Priority:** `medium`
> **Owner repo:** `learning_ai_flowmonk`
> **Type:** optional product enhancement

#### Current state

FlowMonk already has:

- direct runtime sessions, tasks, todos, runs, approvals, actions, and checkpoints
- direct user-managed runtime editing surfaces
- runtime review UI with run filtering, action drill-in, checkpoint guidance, and replay-oriented inspection
- live end-to-end verification with Playwright

#### Opportunity

Add richer replay execution controls on top of the current review experience, such as:

- replaying one selected planning action or approval path
- selectively re-running a failed or cancelled planning step
- previewing the effect of replay before execution
- capturing replay outcomes as explicit runtime actions

#### Why it is optional

The current review surface already satisfies the baseline need:

- inspect what happened
- inspect why it happened
- inspect the payload
- inspect the run context

Execution controls add complexity and should only be introduced if the review-only surface proves insufficient in real use.

#### Dependencies

- stable FlowMonk runtime semantics
- stable ActionTrail replay expectations from the shared runtime contract
- product decision on which actions are safely replayable

#### Acceptance criteria

- [x] replayable actions are explicitly scoped and documented
- [x] replay execution is blocked for unsafe or ambiguous action types
- [x] replay creates runtime audit evidence
- [x] user-facing warnings explain what will and will not happen during replay
- [x] focused backend, UI, and e2e coverage exists

#### Risks

- replay can create accidental duplicated planning state
- users may confuse “inspect replay” with “execute replay”
- replaying side-effectful actions without strong guardrails would be unsafe

#### Implementation notes

- FlowMonk now exposes replay preview and replay execution endpoints for a narrow, deterministic subset of runtime actions.
- unsupported actions remain review-only and return explicit preview reasons instead of silently attempting replay.
- live Playwright verification now covers replay preview and replay execution through the runtime review UI.

#### Commits

- `8176395` implemented safe replay preview and execution controls in `learning_ai_flowmonk`

---

### 2.2 Cowork richer checkpoint drill-in

> **Status:** implemented

> **Priority:** `medium`
> **Owner repo:** `oss/learning_ai_claw-cowork`
> **Type:** optional product enhancement

#### Current state

Cowork already has:

- canonical runtime session, task, todo, run, approval, and action projections
- canonical audit event IDs
- persisted checkpoint surfaces
- checkpoint summaries with artifact, memory, and artifact-id references when available

#### Opportunity

Add deeper checkpoint drill-in, such as:

- checkpoint timeline per session or task
- richer diff between adjacent checkpoints
- direct navigation from a checkpoint to referenced artifact or memory details
- replay or resume preparation view from one chosen checkpoint

#### Why it is optional

The current checkpoint summaries are already sufficient for the roadmap baseline:

- checkpoint existence is visible
- linked refs are visible
- session/task/runtime lineage is preserved

Richer drill-in is useful for power-user inspection, but not required to keep the shared runtime contract valid.

#### Dependencies

- stable Cowork checkpoint schema
- stable session/task canonical event IDs
- clear product decision on how much checkpoint detail should be exposed in desktop UI versus service projections

#### Acceptance criteria

- [x] checkpoint drill-in shows meaningful incremental state beyond the summary row
- [x] linked artifact and memory refs can be opened or traced cleanly
- [x] session/task context remains clear throughout drill-in
- [x] the UI clearly distinguishes direct observations from projected summaries
- [x] Rust and service-level tests cover the richer checkpoint shape

#### Risks

- checkpoint detail can become noisy if every internal snapshot is surfaced
- drill-in UI can expose implementation detail without user value
- replay/resume affordances may be confused with guaranteed deterministic restoration

#### Implementation notes

- `cowork-service` now exposes a checkpoint-detail route for one persisted Cowork checkpoint
- the hosted admin runtime console now includes a dedicated Cowork checkpoint tab with drill-in detail
- the drill-in explicitly separates persisted Cowork observations from projected runtime summary fields
- checkpoint-linked artifact, memory, and approval refs are surfaced directly in the review panel

#### Commits

- `7240de7` added direct checkpoint artifact IDs to Cowork runtime IPC
- `59ae0e1` added the shared checkpoint artifact contract and projection mapping
- `82a44c2` added checkpoint-detail routing and hosted Cowork drill-in review

---

## 3. Priority Guidance

Take these only when:

1. the baseline roadmap is stable and no longer needs hardening
2. real product usage shows that review-only visibility is not enough
3. the enhancement can be tested end to end without degrading the current stable paths

Recommended order if both are chosen:

1. FlowMonk richer replay execution controls
2. Cowork richer checkpoint drill-in

Reason:

- FlowMonk already has a richer user-facing runtime review surface, so the next incremental step is clearer
- Cowork checkpoint drill-in is valuable, but more likely to expose internal detail that still needs product judgment

---

## 4. Tracking Rules

- keep optional work out of the baseline phase checklists unless it becomes required
- when one of these items is started, add the implementation commits here and update the main tracker summary
- if an optional item becomes mandatory due to product or safety needs, move it back into `ECOSYSTEM_IMPLEMENTATION_TRACKER.md`

## 5. Commits

- `cedfacc` established that the baseline roadmap hardening is complete and these remaining items are optional
- `cff76d9` created this optional enhancement backlog
