From 152b294d3883d8643e301a490d3d530ee5261a60 Mon Sep 17 00:00:00 2001 From: Saravana Achu Mac Date: Sat, 4 Apr 2026 04:14:32 -0700 Subject: [PATCH] docs(ecosystem): mark FlowMonk runtime integration complete --- docs/ecosystem/ECOSYSTEM_IMPLEMENTATION_TRACKER.md | 8 ++++---- .../PHASE5_AGENT_RUNTIME_CONTRACT_EXECUTION_PLAN.md | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/ecosystem/ECOSYSTEM_IMPLEMENTATION_TRACKER.md b/docs/ecosystem/ECOSYSTEM_IMPLEMENTATION_TRACKER.md index eacaffc9..04947434 100644 --- a/docs/ecosystem/ECOSYSTEM_IMPLEMENTATION_TRACKER.md +++ b/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? diff --git a/docs/ecosystem/PHASE5_AGENT_RUNTIME_CONTRACT_EXECUTION_PLAN.md b/docs/ecosystem/PHASE5_AGENT_RUNTIME_CONTRACT_EXECUTION_PLAN.md index 84605080..ddd2f04c 100644 --- a/docs/ecosystem/PHASE5_AGENT_RUNTIME_CONTRACT_EXECUTION_PLAN.md +++ b/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?