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

docs(ecosystem): harden adoption coverage and governance

Browse Source
This commit is contained in:
Saravana Achu Mac 2026-04-04 16:44:52 -07:00
parent 065c025854
commit ab50831d28
7 changed files with 238 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
docs/ecosystem/ECOSYSTEM_OWNERSHIP_MATRIX.md
View File

@ -1,6 +1,6 @@
# Ecosystem Ownership Matrix
> **Status:** Draft
> **Status:** Hardened temporary model
> **Owner Model:** temporary four-party operating model
> **Parties:** Saravana, Codex, Windsurf, Cursor
> **Purpose:** Clarify who owns what for ecosystem planning, implementation, review, and tracking.
@ -111,21 +111,55 @@ This is not exclusive ownership. It is the default lead bias.
4. Saravana remains the final authority on tradeoffs and sequencing.
5. Every major ecosystem task should be visible in the tracker with one clear owner.
## 6. Revision Trigger
This ownership model must be revised when any of these become true:
1. the working team grows beyond Saravana, Codex, Windsurf, and Cursor
2. one product repo gains a stable long-term owner outside the current four-party group
3. release authority becomes shared across multiple humans
4. approval, security, or infra ownership becomes operational rather than ad hoc
If one of those happens, update this document in the same change series that updates:
- `ECOSYSTEM_AGENT_OPERATING_MODEL.md`
- `ECOSYSTEM_IMPLEMENTATION_TRACKER.md`
- the relevant adoption docs
## 7. Next-State Ownership Shape
If the team expands, the preferred next structure is:
- `Saravana`
- product direction
- release authority
- final acceptance
- `Codex`
- shared architecture
- ecosystem contracts
- cross-repo integration review
- `Repo leads`
- one accountable human or agent owner per active product repo
- `Execution agents`
- bounded implementation, verification, and documentation updates under the shared operating model
See also:
- [`ECOSYSTEM_AGENT_OPERATING_MODEL.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/ECOSYSTEM_AGENT_OPERATING_MODEL.md) for the detailed delegation, review, merge, and parallelization process.
---
## 6. Implementation Checklist
## 8. Implementation Checklist
- [ ] confirm this temporary four-party ownership model
- [ ] add repo adoption owners as work expands
- [ ] add handoff conventions between Codex, Windsurf, and Cursor
- [x] confirm this temporary four-party ownership model
- [x] add handoff conventions between Codex, Windsurf, and Cursor
- [x] define revision triggers if the team structure changes
- [ ] add repo adoption owners when active ownership expands beyond the current four-party model
- [ ] revise this doc if the team structure changes
Commits:
- `41fa2cd` drafted the initial version
- `7a86a76` updated the ownership language to Saravana
- `pending` linked ownership to the detailed operating model
- `765568f` linked ownership to the detailed operating model
- `065c025` tracked ownership revision as remaining work

32
docs/ecosystem/ECOSYSTEM_VERIFICATION_MATRIX.md
View File

@ -1,6 +1,6 @@
# Ecosystem Verification Matrix
> **Status:** Draft
> **Status:** Hardened baseline
> **Owner:** `learning_ai_common_plat`
> **Purpose:** Define how ecosystem work is verified before it is considered complete.
@ -119,13 +119,37 @@ For every major implementation item, attach:
---
## 6. Implementation Checklist
## 6. Repo-Level Evidence Matrix
- [ ] finalize phase-1 golden flow checks
| Repo | Primary owner | Required evidence | Baseline commands |
| ----------------------------------- | ----------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `learning_ai_common_plat` | Codex | contract changes, tracker updates, route tests, shared type validation | `pnpm --filter @bytelyst/events build`, `pnpm --filter @lysnrai/platform-service exec vitest run ...`, `pnpm --filter @lysnrai/cowork-service exec vitest run ...` |
| `learning_voice_ai_agent` | Codex | transcript producer verification, artifact persistence checks | `python3 -m pytest tests/test_ecosystem_phase1.py -q` |
| `learning_ai_notes` | Windsurf or Codex | import route verification, schema conformance, downstream lineage | `pnpm --filter @notelett/backend run test` or focused Vitest route coverage |
| `learning_multimodal_memory_agents` | Cursor or Codex | memory import verification, runtime path validation, focused web tests | focused Vitest command for the ecosystem import path |
| `learning_ai_flowmonk` | Codex | backend runtime route tests, web build, live runtime browser verification when runtime UI changes | `pnpm --filter @flowmonk/backend exec vitest run src/modules/agent-runtime/routes.test.ts`, `npm run build`, `npx playwright test ...` |
| `learning_ai_clock` | Codex | routine-import verification against the shared artifact contract | focused route or library tests for routine import |
| `learning_ai_efforise` | Codex | habit-import verification against the shared artifact contract | focused route or library tests for habit import |
| `learning_ai_trails` | Codex | trail artifact causation verification and import-path checks | `node --experimental-strip-types --test backend/src/lib/ecosystem-phase3.test.ts` |
| `oss/learning_ai_claw-cowork` | Codex | native Rust verification for audit, session/task projections, and checkpoint surfaces | `cargo test --workspace` |
Rules:
1. Every tracker row that claims completion should cite at least one repo-specific verification command.
2. Cross-repo flows should include both producer and consumer evidence.
3. Live browser or runtime walkthrough evidence is required when user-facing behavior is a first-class requirement, not just a convenience.
---
## 7. Implementation Checklist
- [x] finalize phase-1 golden flow checks
- [x] define repo-level verification owners
- [x] define minimum evidence for “done”
- [ ] add links from tracker rows to verification evidence
- [x] define repo-level evidence ownership and baseline command expectations
- [ ] add links from tracker rows to verification evidence when converting local hashes to fully linked audit rows
Commits:
- `41fa2cd` drafted the initial version
- `065c025` tracked verification hardening as remaining work

4
docs/ecosystem/adoption/README.md
View File

@ -22,6 +22,10 @@ Current docs:
- [`learning_ai_efforise.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/adoption/learning_ai_efforise.md)
- [`learning_ai_trails.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/adoption/learning_ai_trails.md)
- [`learning_ai_claw-cowork.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/adoption/learning_ai_claw-cowork.md)
- [`learning_ai_smart_auth.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/adoption/learning_ai_smart_auth.md)
- [`learning_ai_auth_app.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/adoption/learning_ai_auth_app.md)
- [`learning_ai_mac_tooling.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/adoption/learning_ai_mac_tooling.md)
- [`learning_ai_jarvis_jr.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/adoption/learning_ai_jarvis_jr.md)
Each adoption doc should cover:

42
docs/ecosystem/adoption/learning_ai_auth_app.md Normal file
View File

@ -0,0 +1,42 @@
# Adoption: learning_ai_auth_app
> **Status:** Planned hardening adopter
> **Owner:** `learning_ai_auth_app`
> **Ecosystem focus:** approval capture, decision confirmation, and trust-aware action authorization
---
## Goals
- provide one approval UX for agent, auth, and destructive-action decisions
- consume canonical approval payloads rather than product-specific prompts
- preserve approval lineage for ActionTrail and runtime replay
## Expected Contract Touchpoints
- `ECOSYSTEM_APPROVALS_AND_TRUST_MODEL.md`
- `ECOSYSTEM_EVENT_TAXONOMY.md`
- `ECOSYSTEM_AGENT_RUNTIME_CONTRACT.md`
## Planned Adoption Scope
- consume canonical approval records and shared approval prompt metadata
- support session-scoped and run-scoped approval reuse windows
- render why an approval is required using trust and risk inputs
- emit approval decision events in the canonical event family
## Verification Checklist
- [ ] approval payload renders without product-specific branching
- [ ] approval decisions map into canonical approval events
- [ ] approval reuse, expiry, and denial states are visible to downstream consumers
- [ ] tracker updated with implementation commit links
## Risks
- approval UX may become too generic unless action-specific context is preserved
- stale approval decisions would be dangerous if expiry and reuse rules are weak
## Commits
- `065c025` added this adoption plan

42
docs/ecosystem/adoption/learning_ai_jarvis_jr.md Normal file
View File

@ -0,0 +1,42 @@
# Adoption: learning_ai_jarvis_jr
> **Status:** Planned hardening adopter
> **Owner:** `learning_ai_jarvis_jr`
> **Ecosystem focus:** shared runtime consumption, delegated execution, and marketplace alignment
---
## Goals
- consume shared runtime and approval contracts rather than introducing a parallel agent model
- reuse ecosystem marketplace inventory and entitlement concepts
- preserve delegated-action lineage for timeline and replay
## Expected Contract Touchpoints
- `ECOSYSTEM_AGENT_RUNTIME_CONTRACT.md`
- `ECOSYSTEM_APPROVALS_AND_TRUST_MODEL.md`
- `ECOSYSTEM_MARKETPLACE_UNIFICATION.md`
- `ECOSYSTEM_EVENT_TAXONOMY.md`
## Planned Adoption Scope
- consume shared session, run, todo, and approval semantics
- publish or consume marketplace inventory through the shared listing model
- render delegated-agent actions as canonical events and approval records
## Verification Checklist
- [ ] delegated tasks map into the shared runtime objects cleanly
- [ ] marketplace inventory can be rendered from the shared listing model
- [ ] approval and replay semantics remain consistent with Cowork and FlowMonk
- [ ] tracker updated with implementation commit links
## Risks
- JarvisJr may want richer delegation semantics than the initial runtime baseline
- marketplace expectations may exceed the first shared listing model
## Commits
- `065c025` added this adoption plan

40
docs/ecosystem/adoption/learning_ai_mac_tooling.md Normal file
View File

@ -0,0 +1,40 @@
# Adoption: learning_ai_mac_tooling
> **Status:** Planned hardening adopter
> **Owner:** `learning_ai_mac_tooling`
> **Ecosystem focus:** device posture and local execution trust signals
---
## Goals
- provide device posture signals to the shared approvals and trust model
- avoid each local-first product inventing its own device-risk rules
- allow risk changes to alter runtime approval behavior without product-local rewrites
## Expected Contract Touchpoints
- `ECOSYSTEM_APPROVALS_AND_TRUST_MODEL.md`
- `ECOSYSTEM_EVENT_TAXONOMY.md`
## Planned Adoption Scope
- map mac-tooling posture into canonical device trust levels
- emit trust change events when device posture degrades or recovers
- expose enough signal for Cowork, Auth App, and SmartAuth to make consistent step-up decisions
## Verification Checklist
- [ ] device posture maps cleanly into canonical trust levels
- [ ] trust changes emit canonical trust events
- [ ] downstream approval policy can react without product-specific adapters
- [ ] tracker updated with implementation commit links
## Risks
- device posture can be noisy and may create false-positive trust degradation
- different device signals may need weighting before they become blocking inputs
## Commits
- `065c025` added this adoption plan

42
docs/ecosystem/adoption/learning_ai_smart_auth.md Normal file
View File

@ -0,0 +1,42 @@
# Adoption: learning_ai_smart_auth
> **Status:** Planned hardening adopter
> **Owner:** `learning_ai_smart_auth`
> **Ecosystem focus:** identity trust signals for approvals, runtime gating, and step-up policy
---
## Goals
- expose identity trust state through shared ecosystem trust semantics
- provide reusable step-up decisions to Auth App and runtime consumers
- avoid product-local approval policy forks
## Expected Contract Touchpoints
- `ECOSYSTEM_APPROVALS_AND_TRUST_MODEL.md`
- `ECOSYSTEM_EVENT_TAXONOMY.md`
- `ECOSYSTEM_AGENT_RUNTIME_CONTRACT.md`
## Planned Adoption Scope
- map SmartAuth identity posture into canonical trust levels
- emit trust-related events without leaking provider-specific auth details
- provide reusable approval prerequisites to Cowork, FlowMonk, and future agent products
- support approval reuse decisions based on identity trust state
## Verification Checklist
- [ ] identity trust levels map cleanly into the shared taxonomy
- [ ] step-up-required cases are emitted or exposed consistently
- [ ] approval consumers can evaluate SmartAuth trust state without provider-specific logic
- [ ] tracker updated with implementation commit links
## Risks
- auth-provider-specific signals may not map cleanly into one canonical trust model
- over-sharing auth internals would create security and privacy risk
## Commits
- `065c025` added this adoption plan