bytelyst/learning_ai_common_plat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(ecosystem): tighten remaining runtime blockers

Browse Source
This commit is contained in:
Saravana Achu Mac 2026-04-04 02:21:28 -07:00
parent 48c9e51f43
commit 2fdeb136e4
3 changed files with 15 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/ecosystem/ECOSYSTEM_IMPLEMENTATION_TRACKER.md
View File

@ -253,6 +253,12 @@ These should be resolved before claiming the ecosystem docs are fully implementa
- FlowMonk: finish direct runtime-emitter integration once the local npm registry and backend dependencies are available again.
- 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?
---
## 7. Active Execution Plan

2
docs/ecosystem/PHASE4_PERSONAL_TIMELINE_EXECUTION_PLAN.md
View File

@ -1,7 +1,7 @@
# Phase 4 Execution Plan
> **Flow:** Shared personal timeline over the first three ecosystem flows
> **Status:** Service and first hosted UI implemented
> **Status:** Done
> **Owner:** `learning_ai_common_plat`
> **Purpose:** Turn the personal timeline PRD into a reusable contract and baseline aggregator so the first three ecosystem flows can be rendered as one coherent activity stream.

8
docs/ecosystem/PHASE5_AGENT_RUNTIME_CONTRACT_EXECUTION_PLAN.md
View File

@ -95,9 +95,17 @@ Observed baseline:
- `fe36296` platform-service runtime projection + dispatch validation
- `71ef2ac` admin-web hosted runtime console
- `023826e` cowork-service runtime projection routes
- `01201f8` cowork-service runtime task projection
- `b8242b4` cowork-service runtime action-log projection
## 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.
- 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?