docs: complete core ecosystem planning set

This commit is contained in:
Saravana Achu Mac 2026-04-03 16:03:48 -07:00
parent 41fa2cd767
commit 7a86a767b1
9 changed files with 348 additions and 20 deletions

View File

@ -49,8 +49,8 @@ Example:
| `ECOSYSTEM_OWNERSHIP_MATRIX.md` | in-progress | `learning_ai_common_plat` | temporary four-party ownership model added | pending current commit |
| `ECOSYSTEM_VERIFICATION_MATRIX.md` | in-progress | `learning_ai_common_plat` | draft verification model added | pending current commit |
| `ECOSYSTEM_CONTRACT_TEST_STRATEGY.md` | in-progress | `learning_ai_common_plat` | draft contract-test model added | pending current commit |
| `ECOSYSTEM_MARKETPLACE_UNIFICATION.md` | not-started | `learning_ai_common_plat` | depends on artifact/runtime conventions | — |
| `ECOSYSTEM_PERSONAL_TIMELINE_PRD.md` | not-started | `learning_ai_common_plat` | depends on artifacts + events | — |
| `ECOSYSTEM_MARKETPLACE_UNIFICATION.md` | in-progress | `learning_ai_common_plat` | draft exists, inventory and entitlement details open | pending current commit |
| `ECOSYSTEM_PERSONAL_TIMELINE_PRD.md` | in-progress | `learning_ai_common_plat` | draft exists, hosting and filtering decisions open | pending current commit |
---
@ -87,6 +87,15 @@ Example:
- [x] Draft contract-test strategy
Commits:
- pending current commit
- [x] Draft marketplace unification spec
Commits:
- pending current commit
- [x] Draft personal timeline PRD
Commits:
- pending current commit
- [x] Draft first adoption docs for transcript -> note -> memory flow
Commits:
- pending current commit
### First implementation tracks
@ -121,7 +130,7 @@ Example:
## 4. Current Gaps Before Broad Implementation
- [ ] event taxonomy needs phase-1 event list hardening
- [ ] no shared adoption docs exist yet under `docs/ecosystem/adoption/`
- [ ] adoption docs exist for the first flow, but broader repo coverage is still missing
- [ ] ownership model is temporary and must be revised if the team changes
- [ ] verification matrix needs repo-level test ownership
- [ ] contract-test strategy needs fixture location and validation tooling decisions

View File

@ -0,0 +1,131 @@
# Ecosystem Marketplace Unification
> **Status:** Draft
> **Owner:** `learning_ai_common_plat`
> **Purpose:** Define one marketplace model for reusable ecosystem assets across products.
---
## 1. Problem
Marketplace-like concepts already exist or are implied across the ecosystem:
- JarvisJr agent marketplace ideas
- Cowork plugin marketplace
- Note templates
- FlowMonk workflows
- ChronoMind routines
- EffoRise programs
- prompt packs, skill packs, department agents
Without one shared marketplace model:
- assets are siloed by product
- monetization is fragmented
- entitlement logic is duplicated
- creators cannot publish once and reach multiple products
---
## 2. Goal
Create one inventory and entitlement model that can support multiple asset types while allowing product-specific presentation.
---
## 3. Canonical Inventory Types
The marketplace should support at least:
- `agent`
- `plugin`
- `connector`
- `skill-pack`
- `prompt-pack`
- `workflow-template`
- `note-template`
- `routine-pack`
- `habit-program`
- `review-template`
Each listing should declare:
- `listingId`
- `inventoryType`
- `title`
- `summary`
- `publisher`
- `supportedProducts`
- `deliveryMode`
- `version`
- `entitlementModel`
---
## 4. Delivery Modes
Supported delivery modes should include:
- config-only
- document/template bundle
- runtime plugin
- connector integration
- agent behavior pack
- prompt or skill bundle
---
## 5. Phase-1 Scope
Start with these inventory types:
- [ ] `plugin`
- [ ] `workflow-template`
- [ ] `note-template`
- [ ] `routine-pack`
- [ ] `skill-pack`
These map directly to existing ecosystem capabilities.
---
## 6. First Adopters
1. `oss/learning_ai_claw-cowork`
2. `learning_ai_flowmonk`
3. `learning_ai_notes`
4. `learning_ai_clock`
5. `learning_ai_jarvis_jr`
---
## 7. Open Decisions
1. Should one listing support multiple delivery modes?
2. Should entitlement be product-scoped or ecosystem-scoped by default?
3. How should version compatibility be represented across products?
4. Which assets require review/signing before distribution?
---
## 8. Acceptance Criteria
1. One creator asset can target more than one product.
2. Platform entitlements can gate access without per-product duplication.
3. Cowork marketplace assets can map into the shared listing model.
4. Product-specific presentation does not require product-specific listing storage.
---
## 9. Implementation Checklist
- [ ] define canonical listing schema
- [ ] define inventory type taxonomy
- [ ] define entitlement model
- [ ] define compatibility/version model
- [ ] define phase-1 publishing workflow
- [ ] define review/signing requirements
Commits:
- initial draft: pending

View File

@ -2,7 +2,7 @@
> **Status:** Draft
> **Owner Model:** temporary four-party operating model
> **Parties:** User, Codex, Windsurf, Cursor
> **Parties:** Saravana, Codex, Windsurf, Cursor
> **Purpose:** Clarify who owns what for ecosystem planning, implementation, review, and tracking.
---
@ -11,7 +11,7 @@
For now, the ecosystem is effectively operated by four parties:
1. **You**
1. **Saravana**
Product owner, final technical decider, integration sponsor, and release authority.
2. **Codex**
High-power architecture and implementation driver for complex cross-repo work.
@ -26,7 +26,7 @@ This document assumes no larger team structure exists yet.
## 2. Role Definitions
### You
### Saravana
Own:
@ -69,16 +69,16 @@ Own:
## 3. Responsibility Matrix
| Work Type | You | Codex | Windsurf | Cursor |
| ---------------------------------- | --- | ----- | -------- | ------ |
| ecosystem strategy | A | R | C | C |
| shared contracts | A | R | C | C |
| cross-repo implementation planning | A | R | C | C |
| high-complexity integration work | A | R | C | I |
| medium repo-local implementation | C | C | R | I |
| low-risk guided edits | C | C | C | R |
| tracker and commit-link hygiene | A | R | C | C |
| final push/go-live decision | A | C | I | I |
| Work Type | Saravana | Codex | Windsurf | Cursor |
| ---------------------------------- | -------- | ----- | -------- | ------ |
| ecosystem strategy | A | R | C | C |
| shared contracts | A | R | C | C |
| cross-repo implementation planning | A | R | C | C |
| high-complexity integration work | A | R | C | I |
| medium repo-local implementation | C | C | R | I |
| low-risk guided edits | C | C | C | R |
| tracker and commit-link hygiene | A | R | C | C |
| final push/go-live decision | A | C | I | I |
Legend:
@ -99,7 +99,7 @@ This is not exclusive ownership. It is the default lead bias.
| shared contract docs | Codex |
| implementation tracker updates | Codex |
| product-local adoption docs | Windsurf or Cursor under guidance |
| final prioritization and acceptance | You |
| final prioritization and acceptance | Saravana |
---
@ -108,7 +108,7 @@ This is not exclusive ownership. It is the default lead bias.
1. If a change affects more than one repo or defines a shared contract, Codex should lead.
2. If a change is bounded to one repo and the contract is already clear, Windsurf can lead.
3. Cursor should be used only for narrower, strongly-scoped work until the ecosystem contracts harden further.
4. You remain the final authority on tradeoffs and sequencing.
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.
---

View File

@ -0,0 +1,110 @@
# Ecosystem Personal Timeline PRD
> **Status:** Draft
> **Owner:** `learning_ai_common_plat`
> **Purpose:** Define a shared user activity timeline that makes cross-product behavior visible and useful.
---
## 1. Problem
The ecosystem can produce many meaningful user events and artifacts, but users cannot yet see them as one coherent stream.
Examples:
- transcript captured in LysnrAI
- note created in NoteLett
- memory created in MindLyst
- plan created in FlowMonk
- routine executed in ChronoMind
- agent run completed in Cowork
- approval granted in Auth App
Without a personal timeline:
- the ecosystem feels fragmented
- provenance is hard to understand
- “one action, many outcomes” is invisible
---
## 2. Product Goal
Give Saravana and future users one place to answer:
- what happened?
- what created it?
- what did it affect?
- what needs follow-up?
---
## 3. Timeline Inputs
The timeline should consume:
- canonical ecosystem events
- canonical artifact envelopes
- approval records
- selected trust/risk changes
---
## 4. Phase-1 User Stories
- [ ] As a user, I can see that one dictated transcript became a note and a memory candidate.
- [ ] As a user, I can see that one plan generated a routine and a habit.
- [ ] As a user, I can see that one Cowork run produced an output and required an approval.
- [ ] As a user, I can trace each item back to its source product and action.
---
## 5. Minimum Timeline Item Shape
```ts
type TimelineItem = {
itemId: string;
occurredAt: string;
eventName: string;
productId: string;
title: string;
summary?: string | null;
artifactRefs: string[];
relatedEventIds: string[];
actorType: 'user' | 'agent' | 'system' | 'device';
visibility: 'private' | 'org' | 'shared' | 'local-only';
};
```
---
## 6. Open Decisions
1. Should the first timeline UI live in admin-web, a new user-facing web shell, or NoteLett/MindLyst?
2. Which events are too noisy for the user-facing timeline?
3. How should local-only events from local-memory products be represented?
4. Should timeline items be materialized or queried live from event/artifact sources?
---
## 7. Acceptance Criteria
1. The two phase-1 golden flows can be rendered in one unified timeline.
2. Timeline items can link back to underlying artifacts and source products.
3. Users can tell which outputs were created automatically vs manually.
4. Approval and trust transitions can be surfaced when relevant.
---
## 8. Implementation Checklist
- [ ] define timeline item contract
- [ ] define event-to-timeline inclusion rules
- [ ] define artifact linking behavior
- [ ] define noise filtering rules
- [ ] define phase-1 UI hosting choice
- [ ] define verification flow using golden paths
Commits:
- initial draft: pending

View File

@ -22,8 +22,8 @@ Recommended structure:
- [`ECOSYSTEM_OWNERSHIP_MATRIX.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/ECOSYSTEM_OWNERSHIP_MATRIX.md) — temporary four-party ownership model
- [`ECOSYSTEM_VERIFICATION_MATRIX.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/ECOSYSTEM_VERIFICATION_MATRIX.md) — what “done” means for cross-product features
- [`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` — shared marketplace model
- `ECOSYSTEM_PERSONAL_TIMELINE_PRD.md` — unified user activity stream
- [`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
- [`adoption/`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/adoption) — per-product adoption notes
Ownership model:

View File

@ -12,6 +12,12 @@ Recommended file pattern:
- `learning_ai_trails.md`
- `oss_learning_ai_claw_cowork.md`
Current docs:
- [`learning_voice_ai_agent.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/adoption/learning_voice_ai_agent.md)
- [`learning_ai_notes.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/adoption/learning_ai_notes.md)
- [`learning_multimodal_memory_agents.md`](/Users/saravana/BytelystAI/learning_ai/learning_ai_common_plat/docs/ecosystem/adoption/learning_multimodal_memory_agents.md)
Each adoption doc should cover:
- shared contracts consumed

View File

@ -0,0 +1,24 @@
# Adoption: learning_ai_notes
> **Status:** Draft
> **Owner:** `learning_ai_notes`
> **Ecosystem focus:** transcript -> note -> memory golden flow
---
## Goals
- consume transcript-derived artifacts
- store note artifacts using the shared envelope
- preserve provenance and downstream memory linking
## Checklist
- [ ] accept transcript-linked artifact creation
- [ ] emit canonical note artifact envelope
- [ ] emit `artifact.created` and `artifact.linked`
- [ ] preserve provenance to transcript source
Commits:
- pending

View File

@ -0,0 +1,24 @@
# Adoption: learning_multimodal_memory_agents
> **Status:** Draft
> **Owner:** `learning_multimodal_memory_agents`
> **Ecosystem focus:** transcript -> note -> memory golden flow
---
## Goals
- consume note and transcript provenance
- create or propose memory artifacts using the shared envelope
- preserve lineage to upstream sources
## Checklist
- [ ] accept transcript and note artifact references
- [ ] emit canonical memory artifact envelope
- [ ] emit `memory.entry.created`
- [ ] preserve lineage to source artifacts
Commits:
- pending

View File

@ -0,0 +1,24 @@
# Adoption: learning_voice_ai_agent
> **Status:** Draft
> **Owner:** `learning_voice_ai_agent`
> **Ecosystem focus:** transcript -> note -> memory golden flow
---
## Goals
- emit canonical transcript artifacts
- emit canonical capture events
- provide enough provenance for downstream NoteLett and MindLyst consumers
## Checklist
- [ ] map transcript output to shared artifact schema
- [ ] emit `capture.transcript.created`
- [ ] include correlation/session IDs for downstream linking
- [ ] document downstream handoff contract to NoteLett and MindLyst
Commits:
- pending