docs(ecosystem): mark FlowMonk runtime integration complete

docs/ecosystem/ECOSYSTEM_IMPLEMENTATION_TRACKER.md

@@ -238,24 +238,24 @@ These should be resolved before claiming the ecosystem docs are fully implementa
     Status note:
   - admin-web now exposes `/agent-runtime` over the shared platform runtime API
   - the first hosted internal runtime UI supports projected session review, projected run review, and dispatch payload validation
-- [ ] wire first product implementations to emit the shared runtime objects directly from Cowork and FlowMonk
+- [x] wire first product implementations to emit the shared runtime objects directly from Cowork and FlowMonk
       Status note:
   - Cowork product-native runtime projections are now implemented in cowork-service
   - `023826e` adds `GET /api/agent-runtime/sessions`, `GET /api/agent-runtime/runs`, `GET /api/agent-runtime/approvals`, and `POST /api/agent-runtime/dispatch/validate`
   - `01201f8` adds `GET /api/agent-runtime/tasks` with canonical `AgentTask` projection
   - `b8242b4` adds `GET /api/agent-runtime/actions` with canonical `AgentActionLog` projection
-  - FlowMonk runtime-emitter implementation work was started, but this clone cannot currently verify it because the repo depends on a local npm registry at `http://localhost:3300` and backend dependencies are not installed
+  - FlowMonk local installs now resolve `@bytelyst/*` from the sibling `learning_ai_common_plat` workspace instead of the dead localhost registry
+  - `1ccafa7` adds FlowMonk direct runtime projections for sessions, tasks, runs, action logs, and dispatch validation
 
 ### 6.1 Remaining Direct Runtime TODOs
 
 - Cowork: add `AgentTodo` direct projection once the product exposes first-class todo entities.
 - Cowork: attach canonical event IDs to approval and audit trails so ActionTrail lineage can stop using fallback/null semantics.
-- FlowMonk: finish direct runtime-emitter integration once the local npm registry and backend dependencies are available again.
+- FlowMonk: add direct `AgentApprovalCheckpoint` and `AgentTodo` projections once the product exposes first-class approval/todo primitives.
 - Platform-service: refine the `queued -> paused` projection fallback once run-vs-session semantics are finalized.
 
 ### 6.2 Explicit Blockers And Questions
 
-- Blocked: FlowMonk backend verification cannot run in this clone because its `@bytelyst/*` dependencies still resolve through the unavailable repo-local registry target `http://${GITEA_NPM_HOST}:3300`.
 - Question: should the shared runtime contract add a first-class `queued` run state rather than continuing the current `queued -> paused` fallback projection?
 - Question: should Cowork approval/audit records emit canonical event IDs from Rust so runtime projections and ActionTrail lineage can share the same identifiers?
 

docs/ecosystem/PHASE5_AGENT_RUNTIME_CONTRACT_EXECUTION_PLAN.md

@@ -85,7 +85,7 @@ Observed baseline:
 - [x] define action-log contract
 - [x] verify Cowork-style and FlowMonk-style runtime examples
 - [x] add first product-facing runtime projection and dispatch validation API in platform-service
-- [ ] wire first product implementations to emit the shared runtime objects directly from Cowork and FlowMonk
+- [x] wire first product implementations to emit the shared runtime objects directly from Cowork and FlowMonk
 
 ---
 
@@ -97,15 +97,15 @@ Observed baseline:
 - `023826e` cowork-service runtime projection routes
 - `01201f8` cowork-service runtime task projection
 - `b8242b4` cowork-service runtime action-log projection
+- `1ccafa7` FlowMonk local shared-package resolution + runtime projection routes
 
 ## 7. Remaining Gaps
 
 - Cowork now emits shared runtime projections from cowork-service, but Rust-side canonical event IDs are still missing on approval/audit records and `AgentTodo` still has no first-class product source.
-- FlowMonk runtime-emitter code was started locally, but verification in this clone is blocked because the repo depends on a local npm registry at `http://localhost:3300` and its backend `node_modules` are missing.
+- FlowMonk now emits direct runtime projections for planning sessions, tasks, runs, and action logs, but it still has no first-class approval checkpoint or todo primitive.
 - run-vs-session semantics for queued work still need a stricter mapping than the current projection fallback.
 
 ## 8. Explicit Blockers And Questions
 
-- Blocked: FlowMonk cannot be fully verified in this clone until its `@bytelyst/*` dependencies are installable again. Current blocker is the repo-local `.npmrc` pointing to `http://${GITEA_NPM_HOST}:3300/...` while the required registry is unavailable here.
 - Question: should queued work remain represented as `paused`, or should the shared runtime contract gain a first-class `queued` run state?
 - Question: should Cowork approval and audit records start emitting canonical event IDs from Rust so ActionTrail and runtime lineage can share the same identifiers?