docs(ecosystem): add optional enhancement backlog

docs/ecosystem/ECOSYSTEM_IMPLEMENTATION_TRACKER.md

@@ -45,6 +45,10 @@ Build a shared ByteLyst ecosystem layer so products do not behave like isolated
   - richer FlowMonk replay execution controls if they prove useful
   - richer Cowork checkpoint drill-in if product usage justifies it
 
+Canonical backlog:
+
+- [`OPTIONAL_PRODUCT_ENHANCEMENT_BACKLOG.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/OPTIONAL_PRODUCT_ENHANCEMENT_BACKLOG.md)
+
 ### Current Roadmap Call
 
 - the implementation roadmap baseline is materially complete through Phase 5

docs/ecosystem/OPTIONAL_PRODUCT_ENHANCEMENT_BACKLOG.md

@@ -0,0 +1,162 @@
+# 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
+
+> **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
+
+- [ ] replayable actions are explicitly scoped and documented
+- [ ] replay execution is blocked for unsafe or ambiguous action types
+- [ ] replay creates canonical runtime and audit evidence
+- [ ] user-facing warnings explain what will and will not happen during replay
+- [ ] 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
+
+---
+
+### 2.2 Cowork richer checkpoint drill-in
+
+> **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
+
+- [ ] checkpoint drill-in shows meaningful incremental state beyond the summary row
+- [ ] linked artifact and memory refs can be opened or traced cleanly
+- [ ] session/task context remains clear throughout drill-in
+- [ ] the UI clearly distinguishes direct observations from projected summaries
+- [ ] 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
+
+---
+
+## 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

docs/ecosystem/README.md

@@ -25,6 +25,7 @@ Recommended structure:
 - [`ECOSYSTEM_CONTRACT_TEST_STRATEGY.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/ECOSYSTEM_CONTRACT_TEST_STRATEGY.md) — how to prevent contract drift across repos
 - [`ECOSYSTEM_MARKETPLACE_UNIFICATION.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/ECOSYSTEM_MARKETPLACE_UNIFICATION.md) — shared marketplace model
 - [`ECOSYSTEM_PERSONAL_TIMELINE_PRD.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/ECOSYSTEM_PERSONAL_TIMELINE_PRD.md) — unified user activity stream
+- [`OPTIONAL_PRODUCT_ENHANCEMENT_BACKLOG.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/OPTIONAL_PRODUCT_ENHANCEMENT_BACKLOG.md) — post-baseline product enhancements that are useful but not required
 - [`PHASE1_TRANSCRIPT_NOTE_MEMORY_EXECUTION_PLAN.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/PHASE1_TRANSCRIPT_NOTE_MEMORY_EXECUTION_PLAN.md) — execution-ready plan for the first golden flow
 - [`PHASE2_PLAN_ROUTINE_HABIT_EXECUTION_PLAN.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/PHASE2_PLAN_ROUTINE_HABIT_EXECUTION_PLAN.md) — execution-ready plan for the second golden flow
 - [`PHASE3_COWORK_ACTIONTRAIL_NOTE_MEMORY_EXECUTION_PLAN.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/PHASE3_COWORK_ACTIONTRAIL_NOTE_MEMORY_EXECUTION_PLAN.md) — execution-ready plan for the audited artifact flow