diff --git a/AGENTS.md b/AGENTS.md index d3811f5..64338fd 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1 +1,5 @@ +<<<<<<< Updated upstream This Bun/TypeScript monorepo uses Bun/Vite+, Convex, Effect v4, and Flue; use `@code/*` exports, validate env in `packages/env`, never edit generated files or `repos/`, and keep UI presentational by moving UI state to reusable hooks and business/services/pure logic to dedicated modules. Treat `docs/PRODUCT.md`, `docs/DESIGN.md`, and `docs/TECH.md` as the canonical product, experience, and architecture specifications; read the relevant files before decisions or changes in those domains. Before Flue work, MUST read `.agents/skills/flue/SKILL.md` and use installed-version `flue docs`; after every change, MUST run `bunx ultracite check` on every changed source, script, and agent file (apply `bunx ultracite fix` first when needed), run the affected package's `bun run check-types`, exercise the changed behavior with its targeted runtime or smoke test, then run root `bun run check` and report unrelated pre-existing failures separately. Keep each individual instruction in any `AGENTS.md` to 1–2 dense sentences, replacing stale guidance rather than appending; this limit applies per instruction, not to the whole file. +======= +This Bun/TypeScript monorepo uses Bun/Vite+, Convex, Effect v4, and Flue; use `@code/*` exports, validate env in `packages/env`, never edit generated files or `repos/`, and keep UI presentational by moving UI state to reusable hooks and business/services/pure logic to dedicated modules. Before Flue work, MUST read `.agents/skills/flue/SKILL.md` and use installed-version `flue docs`; after every change, MUST run `bunx ultracite check` on every changed source, script, and agent file (apply `bunx ultracite fix` first when needed), run the affected package's `bun run check-types`, exercise the changed behavior with its targeted runtime or smoke test, then run root `bun run check` and report unrelated pre-existing failures separately; keep every `AGENTS.md` to 1–2 dense sentences by replacing stale guidance rather than appending. +>>>>>>> Stashed changes diff --git a/DESIGN.md b/DESIGN.md new file mode 100644 index 0000000..f03b948 --- /dev/null +++ b/DESIGN.md @@ -0,0 +1,1497 @@ +# Zopo Work OS — Product Design + +> Status: working interaction and interface specification +> Audience: product design, frontend, product engineering, and agent experience teams +> Scope: information architecture, screens, cards, interaction patterns, states, actions, and design principles +> Excludes: backend implementation and low-level infrastructure details + +## 1. Design objective + +Design one calm, persistent interface in which users can supervise many active units of work across multiple organizations, products, projects, teams, and contexts without managing chat threads, model settings, or agent sessions. + +The interface should make a complex autonomous system feel understandable and controllable. + +The primary design challenge is not displaying everything the system knows. It is showing the smallest amount of information required for the user to understand: + +1. What matters. +2. What is happening. +3. What is blocked. +4. What requires human action. +5. What will happen next. +6. Why the system believes what it believes. + +The central interaction principle is: + +> The conversation is the command surface. The work unit is the persistent product object. + +--- + +## 2. Experience principles + +### 2.1 One continuous workspace + +Do not organize the product around chat history, sessions, or thread lists. + +The user should experience one persistent workspace with a composer that can operate globally or inside a selected work unit. + +### 2.2 Work first, machinery second + +The user should see outcomes, blockers, decisions, artifacts, and results. + +Agent names, model choices, runtime state, and infrastructure details should remain hidden unless they help explain progress or debug a failure. + +### 2.3 Progressive disclosure + +Collapsed cards should be scannable. Expanded cards should become rich working surfaces. Deep evidence, raw events, and technical details should be available on demand. + +### 2.4 Calm density + +The product should support dense operational information without feeling like a traditional enterprise dashboard. + +Use hierarchy, spacing, typography, and grouping rather than excessive borders, colors, or permanent panels. + +### 2.5 Human attention is a scarce resource + +The interface should centralize requests for human involvement. Users should not search through cards to discover approvals, blockers, or unanswered questions. + +### 2.6 Context must always be visible + +The user should always know: + +- Which organization they are viewing. +- Which project or portfolio scope is active. +- Whether the composer is global or work-specific. +- Which work unit is selected. +- Whether an action affects external or production systems. + +### 2.7 Provenance should be nearby + +Important claims, decisions, and recommendations should have accessible source indicators. Evidence should be one interaction away, not buried in a separate audit application. + +--- + +## 3. Product language + +Use consistent language across the interface. + +### Organization + +A company, client, or hard context boundary. + +### Project + +A product, application, repository-backed system, or durable operating context. + +### Goal + +A measurable business or product objective. + +### Signal + +A new piece of information that may matter. + +### Candidate + +A proposed unit of work awaiting confirmation. + +### Work unit + +A persistent outcome the system is responsible for progressing. + +### Run + +One execution attempt inside a work unit. + +### Artifact + +A produced or collected output such as a pull request, preview, report, design, or document. + +### Attention item + +A decision, approval, question, blocker, review, or risk that requires human action. + +Avoid exposing terms such as: + +- Agent thread. +- Model context window. +- Harness session. +- VM. +- Sandbox lifecycle. +- Actor wake state. + +These may appear only in technical details or debugging views. + +--- + +## 4. Global information architecture + +The primary desktop layout uses three regions. + +```text +┌─────────────────────────────────────────────────────────────────────┐ +│ Header │ +├───────────────┬───────────────────────────────────┬─────────────────┤ +│ Work index │ Primary workspace │ Context panel │ +│ │ │ │ +│ │ Cards / expanded work / chat │ Evidence, │ +│ │ │ artifacts, │ +│ │ │ preview, tools │ +├───────────────┴───────────────────────────────────┴─────────────────┤ +│ Persistent composer │ +└─────────────────────────────────────────────────────────────────────┘ +``` + +The layout should collapse gracefully on smaller screens. + +### 4.1 Header + +The header provides global orientation and lightweight controls. + +Recommended contents: + +- Current organization switcher. +- Current project or portfolio scope. +- Search or command trigger. +- Attention count. +- Activity indicator. +- User menu. + +Avoid filling the header with model controls, agent selectors, or environment settings. + +### 4.2 Left work index + +The left region is not chat history. + +It contains operational navigation such as: + +- Now. +- Attention. +- Discovery. +- Active work. +- Waiting. +- Review. +- Monitoring. +- Recently completed. +- Goals. +- Projects. +- Knowledge. +- Activity. + +The index should show compact counts and status indicators. + +A project section may show: + +- Project name. +- Health. +- Number of active units. +- Number requiring attention. +- Current goal or release. + +### 4.3 Primary workspace + +The center is where work appears and expands. + +It can show: + +- Portfolio overview. +- Project overview. +- Work-card feed. +- Expanded work unit. +- Global conversation moments. +- Candidate review. +- Attention workflow. +- Results and learning. + +### 4.4 Context panel + +The right panel changes with the selected object. + +Possible contents: + +- Evidence. +- Sources. +- Files. +- Pull request. +- Code changes. +- Preview. +- Test results. +- Research. +- Agent activity. +- Decisions. +- Dependencies. +- Analytics. +- Customer feedback. +- Version history. + +The panel should be hidden or collapsed when there is no relevant content. + +### 4.5 Persistent composer + +The composer remains available across the product. + +It has two scopes: + +```text +Global workspace +``` + +or: + +```text +Working in: Fix Safari OAuth callback failures +``` + +The active scope should be visually obvious but not heavy. + +The composer can accept: + +- Text. +- Files. +- Images. +- Voice. +- Links. +- Source mentions. +- Work-unit references. +- Project references. +- Commands through natural language. + +The user should not have to select a model, agent, or thinking mode. + +--- + +## 5. Primary screens + +## 5.1 Command Center + +The Command Center is the default high-level screen. + +Purpose: + +- Give the user an immediate understanding of the portfolio. +- Show what progressed autonomously. +- Surface only meaningful changes and required actions. + +Recommended sections: + +### Today + +- Highest-value active work. +- Upcoming deadlines. +- Work likely to become blocked. +- Work recently unblocked. + +### Needs attention + +- Approvals. +- Decisions. +- Questions. +- Reviews. +- Risks. + +### Autonomous progress + +- Work advanced since the last visit. +- Newly produced artifacts. +- Verification completed. +- Follow-up candidates. + +### Project health + +For each relevant project: + +- Current goal. +- Active work count. +- Blocker count. +- Recent result. +- Risk or health signal. + +### Recent outcomes + +- Completed work. +- Measured effects. +- Newly captured learnings. + +The Command Center should not become a wall of metrics. It should be an operational briefing. + +## 5.2 Discovery Inbox + +The Discovery Inbox contains signals and candidate work. + +Each item should clearly distinguish raw information from proposed interpretation. + +Views: + +- New signals. +- Candidate work. +- Possible duplicates. +- Suggested links to existing work. +- Low-confidence observations. + +Primary actions: + +- Accept. +- Edit. +- Attach to existing work. +- Merge. +- Defer. +- Dismiss. +- Save as knowledge. +- Ask why. + +Batch actions may be useful for obvious duplicates or low-value signals, but important candidate creation should remain inspectable. + +## 5.3 Project Overview + +The Project Overview presents one product or application context. + +Sections: + +- Project identity and health. +- Current goals. +- Active work. +- Waiting and blocked work. +- Recent releases or outcomes. +- Connected sources. +- Important context documents. +- Team members and responsibility. +- Autonomous activity. + +The screen should answer: + +- What is this project trying to achieve? +- What is moving? +- What is blocked? +- What changed recently? +- What requires the user? + +## 5.4 Work Unit Workspace + +The Work Unit Workspace is the expanded state of a selected card. + +Recommended structure: + +### Work header + +- Outcome-oriented title. +- Organization and project. +- Work type. +- Phase. +- Status. +- Priority. +- Owner or responsible party. +- Last meaningful change. +- Autonomy state. + +### Objective + +- Desired outcome. +- Why now. +- Linked goal. +- Success criteria. +- Scope and non-goals. + +### Current understanding + +A concise system-generated summary separated into: + +- Known. +- Inferred. +- Uncertain. +- Conflicting. + +### Plan + +- Current approach. +- Steps. +- Completed actions. +- Next action. +- Alternative path when relevant. + +### Blockers and dependencies + +Each blocker shows: + +- What is blocked. +- Why. +- Who or what can resolve it. +- Impact of waiting. +- Requested human action. + +### Activity + +A chronological but compressed history of: + +- User instructions. +- Agent progress. +- State changes. +- Decisions. +- Artifacts. +- External actions. +- Verification. + +### Artifacts + +A collection of previews and links for: + +- Pull requests. +- Commits. +- Documents. +- Screenshots. +- Previews. +- Test reports. +- Designs. +- Research. + +### Results + +Visible after publication or completion: + +- Expected result. +- Actual result. +- Measurement window. +- Evidence. +- Unexpected effects. +- Follow-up recommendation. + +### Contextual composer + +The composer remains fixed at the bottom and clearly scoped to the selected work unit. + +## 5.5 Attention Queue + +The Attention Queue is the central human-in-the-loop surface. + +Categories: + +- Decisions. +- Approvals. +- Questions. +- Blockers. +- Reviews. +- Access requests. +- Risk alerts. + +Each item must answer: + +- What is needed? +- Why is it needed? +- What does the system recommend? +- What evidence supports that recommendation? +- What happens after approval? +- What happens if the user does nothing? +- How urgent is it? +- Is the action reversible? + +The queue should support quick review without forcing the user into the full work-unit workspace unless deeper context is needed. + +## 5.6 Activity Stream + +The Activity Stream shows what the autonomous system did. + +It should include meaningful events such as: + +- Work discovered. +- Work updated. +- Run started. +- Plan prepared. +- Code changed. +- Verification completed. +- Artifact created. +- Blocker detected. +- Approval requested. +- Work completed. +- Result measured. + +Avoid filling the stream with every low-level tool call. + +Users can expand an event to inspect technical detail and provenance. + +## 5.7 Results and Learning + +This screen shows completed work as a feedback system rather than an archive. + +Views: + +- Recently completed. +- Monitoring. +- Successful outcomes. +- Unexpected regressions. +- Follow-up opportunities. +- Reusable learnings. + +Each result should connect to the original objective and evidence. + +## 5.8 Knowledge + +The Knowledge screen exposes durable organization and project understanding. + +Categories: + +- Product. +- Business. +- Customers. +- Design. +- Technical context. +- Decisions. +- Known constraints. +- Reusable learnings. + +The user should be able to see whether knowledge is: + +- Canonical. +- Inferred. +- Pending review. +- Outdated. +- Conflicting. + +--- + +## 6. Card system + +The card is a visual projection of a durable product object. + +The same underlying work unit may appear as: + +- Compact card. +- Expanded card. +- Attention item. +- Embedded conversation object. +- Timeline event. +- Result card. + +Do not create separate task systems for each surface. + +## 6.1 Signal card + +Purpose: show newly detected information. + +Collapsed content: + +- Source icon and source name. +- Observation. +- Project or organization. +- Time. +- Suggested relationship. +- Confidence. + +Actions: + +- Create work. +- Attach to existing work. +- Save as knowledge. +- Dismiss. + +Example: + +```text +Support · Acme Corp · 18m ago + +Three users could not finish OAuth setup in Safari. + +Possible match: Fix Safari callback failures +Confidence: High + +[Attach] [Create separate work] [Dismiss] +``` + +## 6.2 Candidate card + +Purpose: propose a durable work unit. + +Collapsed content: + +- Proposed outcome. +- Why it matters. +- Project. +- Linked goal. +- Supporting source count. +- Confidence. +- Duplicate warning if relevant. + +Actions: + +- Accept. +- Edit. +- Merge. +- Defer. +- Dismiss. +- Ask why. + +## 6.3 Active work card + +Purpose: communicate current operational state. + +The collapsed card should answer five questions: + +1. What is this? +2. Why does it matter? +3. What state is it in? +4. Is anything blocked? +5. What happens next? + +Recommended anatomy: + +```text +[Type] [Organization / Project] [Status] + +Fix Safari OAuth callback failures + +Supports: Improve onboarding reliability + +42% complete +Blocked: Need production Safari logs + +Latest: Agent reproduced the issue · 18m ago +Next: Approve temporary logging deployment + +3 artifacts · 5 sources · 2 runs +``` + +## 6.4 Waiting or blocked card + +Waiting should be visually distinct without becoming alarmist. + +Show: + +- Exact blocker. +- Responsible party. +- Time waiting. +- Impact. +- Next resolution action. + +Example: + +```text +Waiting · Approval required + +Fix Safari OAuth callback failures + +Need: Approve 30-minute diagnostic logging +Impact: Investigation cannot continue without production evidence + +[Review request] +``` + +## 6.5 Approval card + +Purpose: let the user make a bounded decision safely. + +Required content: + +- Exact action. +- Why it is requested. +- Recommendation. +- Alternatives. +- Risk. +- Impact. +- Evidence. +- Reversibility. + +Actions: + +- Approve. +- Modify. +- Reject. +- Ask for more evidence. +- Delegate. + +Example: + +```text +Approval required + +Merge PR #184 + +Why: +All automated verification passed. No blocking review issues remain. + +Impact: +Changes OAuth callback validation. No database migration. + +Evidence: +• 14 unit tests passed +• 6 browser tests passed +• Preview reviewed +• Automated code review attached + +[Review changes] [Request changes] [Merge] +``` + +## 6.6 Review card + +Purpose: evaluate an artifact or completed run. + +Show: + +- What changed. +- Acceptance criteria. +- Verification summary. +- Open concerns. +- Preview or diff access. +- Recommended decision. + +Actions: + +- Accept. +- Request changes. +- Continue discussion. +- Compare alternative. +- Stop work. + +## 6.7 Result card + +Purpose: connect completed work to actual outcomes. + +Show: + +- Intended outcome. +- What shipped. +- Expected impact. +- Actual result. +- Measurement period. +- Unexpected effects. +- Suggested follow-up. + +Actions: + +- Accept result. +- Continue monitoring. +- Create follow-up. +- Reopen. +- Roll back where applicable. + +## 6.8 Parent initiative card + +Purpose: summarize a larger outcome composed of several child work units. + +Show: + +- Initiative outcome. +- Progress across children. +- Critical path. +- Current blockers. +- Next milestone. +- Number of active and completed children. + +The parent card should not duplicate every child detail. + +--- + +## 7. Card expansion behavior + +Selecting a work card expands it in place in the primary workspace. + +Recommended behavior: + +- Only one primary card is expanded at a time on desktop. +- Other cards remain visible in the surrounding feed where practical. +- The right panel updates to the selected section or artifact. +- The composer scope changes to the selected work unit. +- The selected card retains its position when collapsed. +- Deep links can open directly to a work unit. + +Expanded work should feel like entering a workspace, not navigating to a disconnected detail page. + +On mobile, the expanded card may use a full-screen sheet or route while preserving the same conceptual model. + +--- + +## 8. Global and contextual chat + +## 8.1 Global mode + +Global mode can create and coordinate work across the active organization or portfolio. + +Example prompts: + +- What needs my attention today? +- Create work for the repeated OAuth complaints. +- Compare onboarding issues across my projects. +- What is blocked for the release? +- Move the pricing experiment behind the reliability work. +- Summarize what progressed overnight. + +Global responses may include embedded work cards and attention items. + +## 8.2 Context mode + +Context mode focuses on one work unit. + +Example prompts: + +- Add Safari 17 to the acceptance criteria. +- Explain the current hypothesis. +- Show me the failing test. +- Try a solution without changing the data model. +- Prepare a smaller pull request. +- Ask the customer for the missing information. + +The composer header should show the active scope and provide an easy way to return to global mode. + +## 8.3 Creating work from chat + +When a user describes work, the system may: + +- Update an existing unit. +- Create a candidate. +- Create accepted work when intent is explicit and policy permits. +- Ask a clarifying question. +- Save the information as knowledge. + +The interface should briefly communicate what happened: + +```text +Created candidate work: Improve OAuth diagnostics +Linked to: Restore OAuth reliability +Sources attached: 3 +``` + +## 8.4 Mentioning work + +Users should be able to reference: + +- A work unit. +- A project. +- A goal. +- An artifact. +- A source. +- A person. + +Mentions should insert structured references without requiring the user to copy IDs or links. + +--- + +## 9. Status design + +Use a small set of user-facing statuses. + +### Proposed + +The system suggests work but has not started it. + +Primary actions: + +- Accept. +- Edit. +- Merge. +- Dismiss. + +### Clarifying + +The outcome or requirements are incomplete. + +Primary actions: + +- Answer question. +- Add context. +- Accept assumption. + +### Ready + +The work is sufficiently defined and can begin. + +Primary actions: + +- Start. +- Review plan. +- Change priority. + +### Active + +The work is progressing. + +Primary actions: + +- Inspect. +- Steer. +- Pause. +- Add context. + +### Waiting + +Progress depends on a person, dependency, approval, or external event. + +Primary actions: + +- Resolve blocker. +- Grant access. +- Make decision. +- Continue waiting. + +### Review + +An artifact or result needs evaluation. + +Primary actions: + +- Approve. +- Request changes. +- Continue discussion. + +### Monitoring + +The work has shipped and the system is watching the outcome. + +Primary actions: + +- Inspect result. +- Extend monitoring. +- Create follow-up. +- Roll back. + +### Done + +The work has reached a completed or intentionally stopped outcome. + +Primary actions: + +- View result. +- Reopen. +- Create follow-up. +- Archive. + +Modifiers: + +- Blocked. +- Approval required. +- Waiting on user. +- Waiting on dependency. +- Running autonomously. +- Scheduled. +- At risk. + +Use text and iconography in addition to color. + +--- + +## 10. Activity design + +Activity should show meaningful product events, not raw agent noise. + +### Primary activity language + +Good: + +- Investigated authentication flow. +- Identified likely state-validation bug. +- Added regression tests. +- Verification passed. +- Pull request created. +- Waiting for merge approval. + +Avoid as primary UI: + +- Called grep. +- Ran shell command. +- Read 34 files. +- Model generated 2,600 tokens. +- Actor woke. + +Low-level events should remain accessible in a technical details drawer. + +### Activity grouping + +Group related events into meaningful sessions: + +```text +Implementation run · 24 minutes + +• Inspected callback handler +• Added state validation +• Added regression tests +• 14 tests passed +• Created PR #184 +``` + +--- + +## 11. Provenance design + +Provenance has four levels. + +### Level 1: Source chips + +Visible directly on cards: + +- Git. +- Support. +- Analytics. +- Conversation. +- System inference. +- Human decision. + +### Level 2: Evidence panel + +Shows sources supporting the current understanding or recommendation. + +### Level 3: Raw source + +Allows the user to inspect the original message, issue, log, file, or event. + +### Level 4: Derivation detail + +For high-impact claims, show: + +- Conclusion. +- Evidence used. +- Assumptions. +- Confidence. +- Conflicting evidence. +- Last updated time. +- Producing agent or process. + +Use labels such as: + +- Verified. +- Reported. +- Inferred. +- Assumed. +- Conflicting. +- Outdated. + +Do not force the user to read derivation detail during normal operation. + +--- + +## 12. Project and organization switching + +Users may manage several organizations and projects. + +Requirements: + +- The active organization must always be visible. +- Switching organizations changes the full product scope. +- The system must not show blended private context across organizations. +- Portfolio views may aggregate counts and summaries with explicit labels. +- The composer should show whether it is operating at portfolio, organization, project, or work-unit scope. + +A hierarchy may look like: + +```text +Portfolio +├── Company A +│ ├── Product Alpha +│ └── Internal Platform +└── Client B + └── Customer Portal +``` + +The interface should not require users to navigate a deep tree for every action. Search, recent projects, and scope-aware commands should provide fast movement. + +--- + +## 13. Project onboarding design + +Project onboarding should feel like preparing a capable working environment, not filling a long settings form. + +## 13.1 Entry choices + +- Start from template. +- Connect existing repository. +- Import repository. +- Create an empty project. + +## 13.2 Template selection + +Initial templates may include: + +- React. +- Hono. +- Express. +- Full-stack web application. +- API service. +- Expo application. +- Monorepo. + +Each template card should explain: + +- What it includes. +- What it is suited for. +- Expected setup time. +- Included verification. + +## 13.3 Context setup + +Guide the user through concise sections for: + +- Product. +- Business. +- Design. +- Technical conventions. +- Agent instructions. + +The system may draft these from repository content or conversation. The user reviews and confirms. + +Avoid forcing users to write complete documents before starting. Allow progressive completion while clearly marking missing context. + +## 13.4 Readiness state + +Show project setup progress: + +- Repository ready. +- Dependencies prepared. +- Context confirmed. +- Verification passed. +- Preview available. +- Agent ready. + +Infrastructure details should appear as plain operational language rather than raw logs. + +--- + +## 14. Artifact experience + +Artifacts should feel first-class within the work unit. + +Supported artifact presentations: + +- Pull request summary. +- Code diff. +- Preview frame. +- Test report. +- Screenshot gallery. +- Research document. +- Design proposal. +- Generated file. +- Release note. + +Each artifact should show: + +- Name. +- Type. +- Producer. +- Time. +- Related run. +- Verification state. +- Review state. +- Source or destination. + +Artifacts should open in the right panel or a focused viewer without breaking the work-unit context. + +--- + +## 15. Human-in-the-loop actions + +The product should support explicit actions rather than vague “continue” buttons. + +Examples: + +- Approve plan. +- Answer question. +- Grant temporary access. +- Review preview. +- Review changes. +- Request revision. +- Approve branch push. +- Approve pull request. +- Approve merge. +- Approve deployment. +- Send message. +- Pause autonomous work. +- Cancel run. +- Reopen work. + +Every sensitive action should show scope and consequence. + +Example: + +```text +Deploy preview + +Project: Zopo Web +Branch: work/W-103/team-invitations +Environment: Temporary preview +External impact: None +Expected duration: 20 minutes + +[Deploy preview] +``` + +--- + +## 16. Autonomy controls + +Do not expose a complex agent-control panel by default. + +Use simple autonomy states: + +- Manual. +- Ask before actions. +- Autonomous within policy. +- Paused. + +Project or organization policy can define defaults. + +A work unit may show: + +```text +Autonomous within policy +No action required +``` + +or: + +```text +Paused after repeated verification failure +Review required +``` + +Advanced settings may expose policy detail, but everyday product use should remain simple. + +--- + +## 17. Empty, loading, and failure states + +## 17.1 Empty workspace + +Do not show a blank dashboard. + +Offer focused starting points: + +- Create project. +- Connect repository. +- Describe what you are working on. +- Import existing issues. +- Start from a template. + +## 17.2 No active work + +Show recent outcomes and suggested candidates rather than inventing busywork. + +## 17.3 Run provisioning + +Show simple language: + +- Preparing workspace. +- Loading project context. +- Starting implementation. + +Avoid exposing infrastructure terms unless the process is delayed or fails. + +## 17.4 Failure state + +A failure should explain: + +- What failed. +- Whether any work was preserved. +- Whether retry is safe. +- What the system recommends. +- Whether human action is required. + +Example: + +```text +Verification failed + +The implementation is saved, but 2 browser tests are failing. +The system recommends another repair attempt. + +[Review failures] [Retry repair] [Stop work] +``` + +## 17.5 Conflicting evidence + +Show conflict explicitly rather than silently choosing one source. + +```text +Conflicting evidence + +Support reports OAuth failures increased. +Analytics currently shows no significant change. + +[Inspect sources] [Continue monitoring] [Start investigation] +``` + +--- + +## 18. Responsive behavior + +### Desktop + +- Three-column layout. +- One expanded work unit. +- Right contextual panel. +- Persistent bottom composer. + +### Tablet + +- Collapsible left index. +- Primary workspace. +- Right panel as overlay or resizable drawer. + +### Mobile + +- Bottom navigation for Now, Attention, Work, and Projects. +- Work cards in a vertical feed. +- Expanded work as a full-screen route or sheet. +- Composer fixed above navigation. +- Context panel content displayed as tabs or sheets. + +The mobile product should prioritize supervision, review, and approval rather than full code inspection. + +--- + +## 19. Visual language + +The visual direction should feel: + +- Calm. +- Precise. +- Premium. +- Spacious. +- Highly legible. +- Modern without looking experimental. + +Recommended characteristics: + +- Warm white or restrained dark backgrounds. +- Soft neutral surfaces. +- Thin separators. +- Large rounded corners. +- Subtle depth. +- Strong typography hierarchy. +- Restrained accent color. +- Selective pastel states for work categories or phases. +- Smooth expansion and scope transitions. + +Avoid: + +- Dense enterprise dashboards. +- Excessive gradients. +- Permanent card borders around every item. +- Bright status colors everywhere. +- Model and agent control clutter. +- Chat bubbles dominating the product. +- Kanban as the default mental model. +- Gamification. + +The product should feel like a focused operating environment, not a collection of AI widgets. + +--- + +## 20. Motion and transitions + +Motion should reinforce state and continuity. + +Use motion for: + +- A card expanding into a workspace. +- Composer scope changing. +- A candidate becoming accepted work. +- An approval resolving and work resuming. +- A new artifact appearing. +- A blocker clearing. + +Avoid decorative motion that distracts from operational information. + +The system should feel alive because work changes meaningfully, not because the interface constantly animates. + +--- + +## 21. Accessibility + +Requirements: + +- Full keyboard navigation. +- Clear focus states. +- Screen-reader labels for status and actions. +- Status not communicated by color alone. +- Sufficient contrast in light and dark modes. +- Reduced-motion support. +- Predictable card expansion. +- Action confirmations for destructive or external effects. +- Human-readable timestamps and relative times with exact-time access. + +--- + +## 22. MVP screen set + +Build the first product around four primary screens: + +1. **Active Work** + - Work-card feed. + - Filters by project and status. + - Expanded work unit. + +2. **Discovery Inbox** + - Signals. + - Candidate work. + - Merge and attach actions. + +3. **Attention Queue** + - Decisions. + - Approvals. + - Questions. + - Reviews. + +4. **Project Overview** + - Goals. + - Active work. + - Project context. + - Artifacts and recent outcomes. + +Persistent across all four: + +- Header. +- Work index. +- Global or contextual composer. +- Realtime activity. + +--- + +## 23. MVP card set + +Initial card types: + +- Signal card. +- Candidate card. +- Active work card. +- Waiting or blocker card. +- Approval card. +- Review card. +- Result card. + +Avoid designing a separate card type for every technical event. Use sections and modifiers inside the core card system. + +--- + +## 24. Design success criteria + +The product experience is successful when a user can answer these questions within seconds: + +- What should I focus on? +- What progressed without me? +- What is blocked? +- What requires my decision? +- Why is this work happening? +- What evidence supports the current understanding? +- What will happen next? +- What changed in the project? +- What result did completed work produce? + +The product should also let the user start, steer, review, or stop work without understanding the internal agent or infrastructure architecture. + +--- + +## 25. Design principles checklist + +Before shipping a screen or feature, verify: + +- Is the primary object a work unit rather than a chat session? +- Is organization and project scope clear? +- Is the next human action obvious? +- Are machine actions separated from human decisions? +- Is provenance available? +- Is uncertainty represented honestly? +- Can detail be progressively disclosed? +- Are technical internals hidden unless useful? +- Does the composer preserve continuity? +- Does the experience reduce coordination rather than create more? + +--- + +## 26. Core experience statement + +Zopo should feel like supervising a capable operating system rather than operating a collection of agents. + +The user opens one workspace, sees the state of meaningful work, resolves the few things requiring judgment, and continues the conversation where needed. The system handles context, execution, progress tracking, and knowledge retention beneath a calm surface organized around persistent outcomes. diff --git a/PRODUCT.md b/PRODUCT.md new file mode 100644 index 0000000..2d1833b --- /dev/null +++ b/PRODUCT.md @@ -0,0 +1,897 @@ +# Zopo Work OS — Product + +> Status: working product specification +> Audience: product, design, operations, research, and agent teams +> Scope: product concepts, product boundaries, product behavior, and user value +> Excludes: implementation details, infrastructure, concrete technology choices, and low-level UI specifications + +## 1. Product summary + +Zopo Work OS is a persistent operating system for technical founders, product engineers, and small software teams who must manage the entire lifecycle of building and growing software across multiple products, companies, repositories, customers, and business functions. + +It replaces fragmented chat sessions, disconnected task trackers, scattered documents, and manually coordinated AI agents with one coherent system organized around **units of work**. + +The user interacts with one continuous workspace. From that workspace, the system discovers work, builds understanding, coordinates execution, requests human judgment when needed, tracks outcomes, and retains the resulting knowledge. + +The product is not a better chat application and not merely another project manager. It is a system that continuously converts company signals into structured, persistent, executable work. + +The core promise is: + +> One workspace that understands the company, turns signals into work, progresses that work autonomously, and brings the human in only when direction, judgment, permission, or taste is required. + +--- + +## 2. Initial customer profile + +The initial ideal customer is a technical founder or small technical team that: + +- Operates one or more software products. +- Works across several companies, client organizations, or repositories. +- Moves constantly between engineering, product, customer support, sales, marketing, operations, and strategy. +- Uses many tools but lacks a single model of what the company is trying to accomplish. +- Already uses AI coding tools but finds their session- and thread-based workflows fragmented. +- Needs more execution capacity without hiring a full department for every function. +- Has a strong need for context continuity, reliable delegation, and visibility into autonomous work. + +Secondary early users may include: + +- Product engineers managing several initiatives. +- Fractional CTOs. +- Technical agencies and studios. +- Solo software entrepreneurs. +- Small product and engineering teams. +- Operators responsible for multiple internal products or client environments. + +The initial product is technical-first because code is a clear execution domain with measurable artifacts, established workflows, and strong user familiarity. The broader product direction includes research, content, marketing, support, product operations, sales enablement, and other forms of knowledge and creative work. + +--- + +## 3. Problem statement + +Modern technical work is fragmented in three ways. + +### 3.1 Work is fragmented across tools + +A single problem may begin in customer support, appear again in analytics, become an issue in a tracker, require research in a browser, turn into code in a repository, produce a pull request, and later require release notes and customer communication. + +Each tool stores a partial view. No tool owns the full lifecycle. + +### 3.2 AI work is fragmented across sessions + +Most AI products organize work around chats, threads, or isolated runs. The user must repeatedly decide: + +- Which conversation to open. +- What context to restate. +- Which model or agent to use. +- Where the result should be stored. +- How the output relates to existing work. +- What changed after the work shipped. + +The conversation becomes the product structure even though conversations are temporary and work is persistent. + +### 3.3 Founders become the coordination layer + +In small teams, the founder acts as the bridge between every system and function. They remember decisions, connect customer feedback to product work, check whether tasks are blocked, move work between tools, review AI outputs, and decide what happens next. + +The founder becomes the human integration bus for the company. + +Zopo Work OS removes this coordination burden by maintaining a persistent model of work, context, state, evidence, execution, and outcomes. + +--- + +## 4. Product thesis + +### 4.1 The conversation is not the product structure + +Conversation is the interface through which the user thinks, directs, reviews, and makes decisions. + +The durable structure is the **work unit**. + +A user should not have to create a new chat because they changed tasks. They should be able to move the scope of one persistent conversation between the whole workspace and a specific work unit. + +### 4.2 Work should be represented as outcomes, not activity + +The system should represent meaningful outcomes such as: + +- Fix Safari OAuth callback failures. +- Reduce onboarding abandonment. +- Launch team invitations. +- Resolve an enterprise billing escalation. +- Rewrite the pricing page. +- Validate a new product direction. + +It should not promote every message, tool call, or agent action into a top-level task. + +### 4.3 The product should participate in the work + +Traditional project-management products store and display work. Zopo should also help discover, understand, plan, execute, verify, publish, and measure it. + +### 4.4 Autonomy should reduce attention, not increase noise + +The product should optimize for useful progress with minimal required human attention. + +Autonomy is successful when the system makes correct progress, keeps the user informed at the right level, and asks for intervention only when it is necessary. + +### 4.5 Knowledge should compound + +Every decision, result, failed approach, customer signal, and artifact should improve the system’s understanding of the organization and make future work faster and more accurate. + +--- + +## 5. Core product objects + +The product should use a small set of durable concepts. These concepts should remain stable even as the product expands into new domains. + +## 5.1 Organization + +An organization is a hard business, permission, and knowledge boundary. + +An organization may represent: + +- A company. +- A client. +- A startup. +- An internal business unit. +- A personal software portfolio. + +An organization owns its users, products, policies, integrations, knowledge, work, and history. + +Information must never move between organizations implicitly. + +## 5.2 Product or project + +A product or project is a durable operating context within an organization. + +It may represent: + +- A software product. +- A repository-backed application. +- A client engagement. +- An internal platform. +- A website or service. +- A focused initiative with its own ongoing context. + +A project contains its goals, product knowledge, working conventions, connected sources, relevant people, and active work. + +Projects should reduce context ambiguity without forcing the user to manually maintain complex folder structures. + +## 5.3 Goal + +A goal states what the organization or project is trying to achieve. + +Examples: + +- Reduce onboarding failure. +- Reach a reliability target. +- Launch enterprise support. +- Improve trial-to-paid conversion. +- Close the first ten enterprise customers. + +Goals help the system distinguish valuable work from merely possible work. + +A work unit may support one or more goals, but every important work unit should have a clear reason for existing. + +## 5.4 Signal + +A signal is raw information that may matter. + +Examples: + +- A support ticket. +- A customer comment. +- An error spike. +- A deployment failure. +- A sales objection. +- A message in a team channel. +- An analytics change. +- A founder’s thought in the global conversation. + +A signal is not automatically a task. + +Signals can be: + +- Attached to existing work. +- Converted into candidate work. +- Saved as knowledge. +- Dismissed. +- Marked as irrelevant or duplicated. + +## 5.5 Candidate work + +Candidate work is a proposed work unit that has not yet been accepted as durable active work. + +The system creates candidates when it believes a signal or cluster of signals deserves action. + +A candidate should explain: + +- What outcome is proposed. +- Why it matters. +- Which evidence supports it. +- Which project and goal it belongs to. +- How confident the system is. +- Whether similar work already exists. + +The user can accept, edit, merge, defer, or dismiss it. + +## 5.6 Work unit + +A work unit is the central object of the product. + +It is a persistent, stateful representation of one meaningful outcome. + +A work unit owns: + +- Objective. +- Desired result. +- Scope and non-goals. +- Current understanding. +- Requirements. +- Success criteria. +- Status. +- Priority. +- Dependencies. +- Blockers. +- Decisions. +- Evidence. +- Plan. +- Human actions. +- Agent activity. +- Artifacts. +- Results. +- Learning. + +The work unit persists across multiple conversations, agent runs, people, tools, and time periods. + +A work unit is not identical to: + +- A single prompt. +- A chat thread. +- A single agent session. +- A pull request. +- A checklist item. +- A repository branch. + +Those may all exist inside or underneath a work unit. + +## 5.7 Step + +A step is a bounded action within a work unit. + +Examples: + +- Inspect relevant logs. +- Reproduce the failure. +- Draft an implementation plan. +- Add tests. +- Review a preview. +- Contact affected customers. + +Steps help organize execution, but they should not become another noisy task-management layer. They are visible when useful and hidden when the user only needs the higher-level outcome. + +## 5.8 Run + +A run is one attempt by an agent or workflow to progress a work unit. + +Examples: + +- Research the root cause. +- Implement a change. +- Review a proposed solution. +- Run verification. +- Prepare release material. + +A work unit can have several runs, including parallel or repeated attempts. + +Runs are subordinate to the work unit and should not replace it as the primary product object. + +## 5.9 Artifact + +An artifact is a durable output or piece of evidence produced or collected during work. + +Examples: + +- Pull request. +- Commit. +- Patch. +- Design. +- Specification. +- Test report. +- Screenshot. +- Preview. +- Research memo. +- Customer response draft. +- Launch plan. + +Artifacts should be attached to the work unit and accessible from its history and current state. + +## 5.10 Decision + +A decision records an important human or system choice and the reasoning behind it. + +Examples: + +- Approve a proposed plan. +- Choose one design direction. +- Reject a migration strategy. +- Delay a feature. +- Accept a known limitation. + +Decisions should remain visible after the immediate conversation is over so future agents do not repeat settled debates. + +## 5.11 Approval + +An approval is a specific human permission required before a sensitive or consequential action. + +Examples: + +- Merge code. +- Deploy to production. +- Send a customer message. +- Access sensitive data. +- Spend money. +- Change business policy. + +Approvals should be precise, inspectable, and bounded. The user should know exactly what will happen after approval. + +## 5.12 Result and learning + +A result records what happened after work was completed or published. + +It should compare: + +- Intended outcome. +- Expected impact. +- Actual outcome. +- Measurement period. +- Unexpected effects. +- Recommended follow-up. + +Learning is the reusable knowledge extracted from the work. It should improve future planning and execution across the relevant organization or project. + +--- + +## 6. Work lifecycle + +Work moves through four broad phases. These phases should remain conceptually consistent across engineering, product, marketing, support, and other domains. + +## 6.1 Discover + +The system observes conversations and connected information sources to identify problems, opportunities, questions, risks, and requests. + +Discovery includes: + +- Extracting signals. +- Grouping related signals. +- Identifying duplicates. +- Connecting signals to existing work. +- Proposing candidate work. +- Relating work to goals and projects. + +The goal of discovery is not to create the largest possible backlog. It is to identify meaningful work with sufficient evidence and relevance. + +## 6.2 Understand + +The system gathers context and develops a shared model of the problem. + +Understanding may include: + +- Research. +- Code or system inspection. +- Customer evidence. +- Analytics. +- Existing decisions. +- Constraints. +- Open questions. +- Risks. +- Success criteria. + +The result should be an actionable understanding, not an endless research report. + +## 6.3 Create and iterate + +The system coordinates the production of a solution. + +Depending on the work, this can include: + +- Code. +- Product specifications. +- Designs. +- Documentation. +- Tests. +- Customer communication. +- Launch assets. +- Research outputs. +- Business recommendations. + +The system should produce intermediate artifacts, verify progress, and incorporate human feedback without losing the work unit’s continuity. + +## 6.4 Publish and learn + +The solution is released, delivered, shared, or otherwise put into use. + +The system then follows the outcome through: + +- Deployment status. +- Error rates. +- Adoption. +- Customer reactions. +- Conversion. +- Support volume. +- Revenue impact. +- Qualitative feedback. + +The lifecycle ends only when the work has either produced a result, been intentionally stopped, or been superseded by another decision. + +--- + +## 7. Work-unit boundaries + +The quality of the system depends heavily on how it divides work. + +## 7.1 A work unit should represent one independently meaningful outcome + +A good work unit can be summarized in one clear sentence and can reach a recognizable result. + +Good examples: + +- Fix Safari OAuth callback failures. +- Decide whether to support SAML this quarter. +- Reduce time-to-first-value during onboarding. +- Prepare and launch the team invitations feature. + +Poor examples: + +- Improve the product. +- Marketing. +- Work on onboarding. +- Open the repository. +- Read the logs. + +The first group is too broad. The second group is too granular. + +## 7.2 Split work when + +A work unit should be split when: + +- It contains multiple independent outcomes. +- Different parts have different owners or approval paths. +- The parts belong to different organizations or permission boundaries. +- They have different deadlines or success criteria. +- One part can finish while another remains active. +- The work has become difficult to summarize or review. +- A child outcome deserves its own lifecycle and result. + +## 7.3 Merge work when + +Work should be merged when: + +- Two candidates describe the same underlying outcome. +- Different channels produced duplicate reports of the same problem. +- One candidate is merely evidence for an existing unit. +- Neither item can be meaningfully completed independently. + +The system may propose a merge, but uncertain merges should remain reversible and user-reviewable. + +## 7.4 Parent and child work + +Large initiatives may contain child work units. + +A parent should represent a larger result, while each child still has an independently meaningful outcome. + +Example: + +**Parent initiative:** Restore OAuth reliability + +- Fix Safari callback failures. +- Improve OAuth setup diagnostics. +- Update documentation. +- Notify affected customers. +- Monitor setup completion after release. + +Parent units should summarize progress and dependencies without replacing the detail of their children. + +--- + +## 8. Conversation model + +The product uses one persistent conversational surface with two scopes. + +## 8.1 Global conversation + +Global conversation is used to think and act across the workspace. + +The user can: + +- Introduce new ideas or problems. +- Ask what needs attention. +- Compare work across projects. +- Reprioritize. +- Create or modify work. +- Ask for summaries. +- Discuss dependencies. +- Request new research or execution. + +The system should automatically connect global messages to relevant projects and work units while preserving the original source. + +## 8.2 Contextual conversation + +Contextual conversation focuses the same composer and interaction model on one work unit. + +The user can: + +- Add requirements. +- Answer questions. +- Review progress. +- Change direction. +- Approve a plan. +- Request another attempt. +- Ask for explanation. +- Continue work from an artifact. + +Entering contextual conversation should not create a new thread. It changes the active scope of the persistent workspace. + +## 8.3 Conversation boundaries + +Conversation should not be the source of truth for work state. + +Important facts, decisions, requirements, approvals, artifacts, and results should be extracted into structured product objects while preserving links to their source conversation. + +--- + +## 9. Autonomous behavior + +The product should continuously observe, understand, organize, execute, escalate, and learn. + +## 9.1 The system may autonomously + +- Attach new evidence to existing work. +- Update summaries and understanding. +- Detect stale or blocked work. +- Propose new work. +- Run safe research. +- Prepare plans and drafts. +- Produce code or other artifacts inside approved boundaries. +- Run verification. +- Suggest priorities. +- Monitor completed work. +- Create follow-up candidates. +- Summarize activity for the user. + +## 9.2 The system should request human involvement for + +- Strategic direction. +- Ambiguous product decisions. +- Business tradeoffs. +- Sensitive permissions. +- High-risk actions. +- External communication. +- Production changes. +- Priority conflicts. +- Conflicting evidence. +- Actions outside previously granted policy. + +## 9.3 The system should not + +- Create large amounts of speculative work without evidence. +- Treat confidence as certainty. +- Hide failures or uncertainty. +- Silently cross organization boundaries. +- Reopen settled decisions without new evidence. +- Perform irreversible actions without appropriate authority. +- Optimize for activity instead of outcomes. + +--- + +## 10. Human-in-the-loop model + +The user should not have to inspect every work unit to find what requires attention. + +The product should centralize human requests into an **Attention Queue**. + +Each request should explain: + +- What is required. +- Why it is required. +- What the system recommends. +- What evidence supports the recommendation. +- What will happen after approval. +- What happens if the user does nothing. +- How urgent the request is. +- Whether the action is reversible. + +Human requests fall into several categories: + +- Decision. +- Approval. +- Clarification. +- Access request. +- Review. +- Blocker resolution. +- Risk alert. + +The product should minimize unnecessary approvals by supporting explicit standing policies, while preserving clear control over sensitive actions. + +--- + +## 11. Provenance and trust + +The user must be able to understand why the system believes something and what caused an action. + +Every important claim should carry provenance. + +Provenance may include: + +- Source message. +- Customer ticket. +- Repository change. +- Error report. +- Analytics event. +- Document. +- Agent observation. +- Human decision. + +Claims should be distinguishable as: + +- Verified. +- Reported. +- Inferred. +- Assumed. +- Conflicting. +- Outdated. + +The primary interface should remain readable, but deeper evidence and derivation should be available on demand. + +The system should never present an agent-generated summary as equivalent to primary evidence. + +--- + +## 12. Knowledge model + +Zopo should accumulate several kinds of organizational knowledge. + +### 12.1 Canonical knowledge + +Durable, reviewed descriptions of: + +- Business. +- Product. +- Customers. +- Design principles. +- Architecture concepts. +- Working conventions. +- Policies. +- Goals. + +### 12.2 Operational knowledge + +Current structured state: + +- Active work. +- Priorities. +- Dependencies. +- Ownership. +- Blockers. +- Approvals. +- Results. + +### 12.3 Episodic knowledge + +What happened over time: + +- Conversations. +- Runs. +- Errors. +- Decisions. +- Reviews. +- Releases. +- Customer reactions. + +### 12.4 Learned patterns + +Reusable conclusions such as: + +- Common causes of failure. +- Customer preferences. +- Repeated objections. +- Effective launch patterns. +- Known limitations. +- Preferred technical and product approaches. + +Knowledge should always retain its scope. Personal preferences, project-specific facts, and organization-wide truths should not be mixed blindly. + +--- + +## 13. Product boundaries + +## 13.1 Zopo is the control layer, not the replacement for every specialist tool + +Specialist systems may continue to own their native records and actions. + +Examples include: + +- Source control. +- Customer support. +- Team communication. +- Analytics. +- Billing. +- Deployment. +- Documents. + +Zopo should provide the unified model of what matters, what state it is in, what should happen next, and whether the outcome worked. + +## 13.2 Zopo should own the work graph + +The work graph connects: + +- Organizations. +- Projects. +- Goals. +- Signals. +- Work units. +- Dependencies. +- Decisions. +- Runs. +- Artifacts. +- Results. +- Learnings. + +This graph is the product’s durable source of coordination and context. + +## 13.3 Execution systems are replaceable + +The product should present execution as a capability beneath the work unit. Users should not have to care which internal agent, model, or harness performed a run unless inspection is useful. + +## 13.4 The product should not expose unnecessary AI configuration + +Users should not normally need to choose: + +- Model. +- Thinking level. +- Agent framework. +- Context-window strategy. +- Execution runtime. +- Tool routing. + +The system should choose automatically based on task, risk, cost, and policy. + +--- + +## 14. Product optimization + +The product should optimize for: + +> Maximum useful progress with minimum required human attention. + +Key product measures include: + +- Correct extraction of meaningful work. +- Low false-positive candidate creation. +- Time from signal to structured understanding. +- Time to first useful action. +- Accepted work units reaching meaningful outcomes. +- Reduction in repeated context gathering. +- Human attention required per completed outcome. +- Quality of decisions and outputs. +- Trust, inspectability, and reversibility. +- Reuse of accumulated knowledge. +- Improvement in future work from past results. + +The product should not primarily optimize for: + +- Number of chats. +- Time spent in the interface. +- Number of tasks created. +- Number of agent runs. +- Number of notifications. +- Raw model usage. + +A successful day may involve the user opening the product briefly, resolving a few high-value decisions, and seeing that many other units progressed correctly without them. + +--- + +## 15. Business value delivered through the product + +Zopo provides four forms of value. + +### 15.1 Execution capacity + +A small team can progress more work without proportionally increasing headcount. + +### 15.2 Coordination reduction + +The product handles the repetitive work of gathering context, updating state, linking related information, following up, and preparing outputs. + +### 15.3 Continuity + +Work keeps its context, history, decisions, and artifacts across tools and time. + +### 15.4 Better opportunity capture + +The system notices recurring problems, customer opportunities, operational risks, and important relationships that the team may otherwise miss. + +--- + +## 16. Initial product scope + +The first strong product loop should be: + +1. The user starts or connects a software project. +2. The product establishes project context. +3. The user describes desired work through the global composer. +4. The system creates or updates a work unit. +5. The work unit is clarified and accepted. +6. The system progresses the work autonomously. +7. The user reviews only necessary decisions and outputs. +8. The system produces verified artifacts. +9. The user approves publication or integration where required. +10. The product updates the work unit and retains the resulting knowledge. + +The first version should prove that persistent work units are a better product structure than disposable agent chats. + +--- + +## 17. Long-term product direction + +The technical product is the starting point, not the final boundary. + +The same work-unit model can later support: + +- Product research. +- Marketing campaigns. +- Content production. +- Sales enablement. +- Customer support operations. +- Pricing work. +- Business analysis. +- Hiring. +- Internal operations. + +The long-term vision is a general operating system for creative and knowledge work. + +The enduring principles are: + +- One persistent workspace. +- Work units instead of chat sessions. +- Outcome-oriented execution. +- Invisible orchestration. +- Explicit human authority. +- Strong provenance. +- Compounding organizational knowledge. + +--- + +## 18. Non-goals for the initial product + +The initial product is not intended to be: + +- A full replacement for every external tool. +- A general-purpose social collaboration platform. +- A traditional kanban board with AI decoration. +- A model playground. +- A prompt-management product. +- A marketplace of visible agents. +- A system that creates work faster than users can evaluate it. +- A fully autonomous company with no human authority. + +--- + +## 19. Product principles + +1. **Organize around work, not conversations.** +2. **Represent outcomes, not activity.** +3. **Keep the system calm while the machinery remains powerful.** +4. **Bring humans in for judgment, not clerical coordination.** +5. **Expose evidence and uncertainty.** +6. **Make important actions understandable and reversible.** +7. **Preserve organization and project boundaries.** +8. **Prefer one coherent model over many disconnected features.** +9. **Let knowledge compound across completed work.** +10. **Measure success by outcomes and reduced attention.** + +--- + +## 20. Working product statement + +Zopo Work OS is an autonomous operating system for technical founders and small product teams. It observes work across the company, turns fragmented signals into persistent units of work, progresses those units using agents and tools, and brings the human in only when judgment, permission, or direction is required. + +It gives the user one continuous workspace for moving from idea or problem to verified, shipped, measurable outcome while preserving context and building a durable understanding of the company over time. diff --git a/TECH.md b/TECH.md new file mode 100644 index 0000000..e10ec54 --- /dev/null +++ b/TECH.md @@ -0,0 +1,1551 @@ + +# Zopo Work OS — Technical Architecture + +> Status: working technical specification +> Audience: engineering, platform, infrastructure, security, and agent teams +> Scope: technical architecture, runtime boundaries, data flow, execution, security, scaling, and implementation decisions +> Assumption: the application begins from an existing Better-T-Stack monorepo with web and Expo applications plus shared packages + +## 1. Technical objective + +Build a multi-tenant Work OS that: + +- Maintains durable organizations, projects, goals, work units, runs, artifacts, and outcomes. +- Provides one global conversation and scoped work-unit conversations. +- Extracts candidate work continuously from conversation and connected systems. +- Runs coding agents inside isolated, reproducible environments. +- Supports autonomous execution while preserving explicit human approval boundaries. +- Streams agent progress into durable work-unit state. +- Produces inspectable artifacts such as commits, pull requests, test reports, previews, documents, and review notes. +- Scales across many organizations, repositories, concurrent work units, and execution environments. +- Keeps execution harnesses and model providers replaceable. + +The central architectural rule is: + +> Work OS owns intent and durable state. Flow agents own orchestration. AgentOS owns agent runtime coordination. Harnesses own individual agent loops. Sandboxes own full-system execution. Git owns source history. Artifact storage owns generated outputs. + +--- + +## 2. High-level architecture + +Separate the system into a **control plane** and an **execution plane**. + +```mermaid +flowchart TB + User[User] + + subgraph Client[Client applications] + Web[Web application] + Mobile[Expo application] + end + + subgraph Edge[Application edge] + API[Application API] + Realtime[Realtime gateway] + end + + subgraph Control[Control plane] + Auth[Identity and tenancy] + WorkGraph[Work graph and relational state] + Conversation[Conversation service] + Flow[Zopo Flow Agent] + Context[Context assembler and memory] + Policy[Policy and approval engine] + Scheduler[Run scheduler and workflow engine] + Events[Event and provenance log] + Notifications[Attention and notification service] + end + + subgraph Shared[Shared services] + Git[Managed or connected Git] + Gateway[Model gateway] + Integrations[Executor / integration gateway] + Secrets[Secrets and workload identity broker] + Artifact[Artifact and object storage] + Search[Retrieval and indexing] + Preview[Preview routing gateway] + Observability[Logs metrics traces and billing] + end + + subgraph Execution[Execution plane] + Actor[AgentOS run actor] + Harness[OpenCode or other ACP harness] + Sandbox[Full Linux sandbox] + Runtime[Project services browsers tests builds] + end + + User --> Web + User --> Mobile + Web --> API + Mobile --> API + Web <--> Realtime + Mobile <--> Realtime + + API --> Auth + API --> WorkGraph + API --> Conversation + API --> Policy + + Conversation --> Flow + WorkGraph --> Flow + Flow --> Context + Flow --> Scheduler + Flow --> Policy + Flow --> Gateway + Flow --> Integrations + + Scheduler --> Actor + Actor <--> Harness + Actor <--> Sandbox + Harness --> Gateway + Harness --> Integrations + Sandbox --> Git + Sandbox --> Runtime + Runtime --> Preview + + Actor --> Events + Sandbox --> Events + Git --> Events + Events --> WorkGraph + Events --> Realtime + Events --> Observability + Artifact --> WorkGraph + Context --> Search + WorkGraph --> Search + Policy --> Notifications +``` + +--- + +## 3. System components and ownership + +## 3.1 Client applications + +The web and Expo applications are product surfaces only. + +They should: + +- Render organization, project, work-unit, run, artifact, and attention state. +- Send user commands through the application API. +- Subscribe to realtime updates. +- Upload attachments through signed or brokered flows. +- Never connect directly to model providers, Git internals, agent harnesses, or sandboxes. + +The frontend should issue domain commands such as: + +- Create work unit. +- Continue work. +- Change composer scope. +- Approve plan. +- Resolve blocker. +- Review artifact. +- Request changes. +- Pause run. +- Cancel run. +- Approve merge. +- Approve deployment. + +## 3.2 Application API + +The application API is the only public backend interface used by product clients. + +Responsibilities: + +- Authentication and authorization. +- Organization and project scoping. +- CRUD for stable domain entities. +- Domain command validation. +- Conversation ingestion. +- Attachment metadata. +- Query endpoints for cards, workspaces, activity, and attention. +- Realtime subscription authorization. +- Idempotency handling. + +Avoid exposing internal runtime APIs directly through the application surface. + +## 3.3 Identity and tenancy + +A user has one Work OS identity. + +Organizations are hard tenancy boundaries. + +Every durable and transient entity must include explicit tenant scope: + +- `organization_id` +- `project_id` where applicable +- `work_unit_id` where applicable +- `run_id` where applicable + +Authorization should be deny-by-default and evaluated on every command and query. + +Cross-organization queries must be explicit portfolio-level operations and must not blend underlying knowledge or execution context. + +## 3.4 Work graph and relational state + +The work graph is the canonical product database. + +Recommended initial implementation: + +- Relational database for authoritative state. +- Event table for append-only provenance and replay. +- Materialized projections for cards, attention, portfolio summaries, and activity feeds. +- Object storage for large artifacts. +- Search index for retrieval. + +Core entities: + +- User. +- Organization. +- Membership. +- Project. +- Project source. +- Goal. +- Signal. +- Candidate. +- Work unit. +- Work-unit relation. +- Step. +- Run. +- Run attempt. +- Agent session. +- Blocker. +- Decision. +- Approval. +- Artifact. +- Source reference. +- Result. +- Learning. +- Conversation message. +- Composer scope. +- Integration connection. +- Policy. +- Workload identity. + +The work-unit record should not be a large agent-authored JSON blob. Store meaningful structured fields and derive summaries through explicit projections. + +## 3.5 Event and provenance log + +All meaningful system changes should be represented as events. + +Example event envelope: + +```json +{ + "event_id": "evt_01...", + "type": "run.verification_completed", + "organization_id": "org_01...", + "project_id": "prj_01...", + "work_unit_id": "wrk_01...", + "run_id": "run_01...", + "actor_type": "agent", + "actor_id": "opencode", + "source_type": "agentos_session", + "source_id": "session_01...", + "sequence": 184, + "payload": { + "summary": "All unit and browser tests passed", + "artifact_ids": ["art_01..."] + }, + "created_at": "2026-07-23T12:00:00Z" +} +``` + +Requirements: + +- Monotonic sequence per run or actor stream. +- Idempotent ingestion. +- Immutable original payload. +- Normalized derived state. +- Traceability from card state to supporting events. +- Explicit distinction between raw evidence, agent interpretation, and human decision. + +## 3.6 Conversation service + +The system maintains a persistent conversation per user workspace with scoped context. + +Messages should contain: + +- Organization scope. +- Optional project scope. +- Optional work-unit scope. +- Author. +- Content blocks. +- Attachments. +- Source references. +- Extraction status. +- Relationship to domain events. + +The conversation service should: + +- Persist the exact user message. +- Publish it for extraction and orchestration. +- Support global and work-unit scope without creating new sessions. +- Allow one message to reference several work units. +- Preserve source links when structured state is extracted. + +## 3.7 Zopo Flow Agent + +The Flow Agent is the orchestration layer above specialist agents. + +Responsibilities: + +- Interpret user intent. +- Extract signals and candidate work. +- Match new information to existing work. +- Detect duplicates and relationships. +- Build or update work briefs. +- Decide whether a human question is required. +- Select an execution strategy. +- Create runs. +- Monitor run events. +- Handle retry, fallback, or escalation decisions. +- Summarize results into work-unit state. +- Create approval requests. +- Propose follow-up work. + +The Flow Agent must not be the sole source of durable truth. Its outputs are validated into domain commands and events. + +It should not directly mutate repositories. Coding work is delegated to a harness running in an isolated execution environment. + +## 3.8 Context and memory layer + +Use four memory classes. + +### Canonical project knowledge + +Versioned, reviewable documents such as: + +- `product.md` +- `design.md` +- `tech.md` +- `business.md` +- `AGENTS.md` +- README files +- decision records +- repository-local conventions + +Prefer storing project-level canonical knowledge in Git alongside the project when practical. + +### Structured operational memory + +Stored in the database: + +- Goals. +- Work-unit state. +- Requirements. +- Decisions. +- Approvals. +- Blockers. +- Dependencies. +- Results. + +### Episodic memory + +Stored as events and transcripts: + +- User messages. +- Agent runs. +- Tool calls. +- Errors. +- Reviews. +- Deployments. +- Human interventions. + +### Retrieval index + +A derived index over: + +- Canonical documents. +- Repository content. +- Conversation. +- Work-unit events. +- Artifacts. +- Connected external sources. + +The retrieval index is not authoritative. It returns source references that are assembled into a run-specific context pack. + +## 3.9 Context assembly + +Do not inject all available knowledge into every run. + +Build a **run context pack** using explicit precedence: + +1. Organization policy. +2. Project goals and canonical context. +3. Repository conventions and instructions. +4. Work-unit objective, requirements, and decisions. +5. Relevant evidence and artifacts. +6. Current run instructions. +7. Runtime and tool constraints. + +Every context item should retain: + +- Source. +- Scope. +- Timestamp. +- Confidence or verification status. +- Revision identifier when applicable. + +Context assembly should be deterministic enough to audit and reproduce. + +## 3.10 Policy and approval engine + +The policy engine sits above harness permissions and runtime capabilities. + +It determines whether an action is: + +- Automatically allowed. +- Allowed under standing policy. +- Requires human approval. +- Denied. + +Policy examples: + +- Create branch automatically. +- Push work branch automatically. +- Create pull request automatically. +- Merge only with approval. +- Deploy preview automatically. +- Deploy production only with approval. +- Never send customer communication without review. +- Never access production data from a default coding run. + +Approval records must include: + +- Exact requested action. +- Parameters. +- Requested capability. +- Evidence and rationale. +- Risk level. +- Expiration. +- User decision. +- Resulting action event. + +## 3.11 Run scheduler and workflow engine + +The scheduler converts accepted work into bounded execution runs. + +Responsibilities: + +- Queue management. +- Tenant quotas. +- Priority. +- Fairness. +- Concurrency limits. +- Run leasing. +- Retry policy. +- Budget allocation. +- Cancellation. +- Workflow checkpoints. +- Waiting for approvals. +- Resuming after approval. + +Run lifecycle: + +```text +queued +→ provisioning +→ preparing +→ running +→ waiting_for_input | verifying | failed | cancelled +→ succeeded +``` + +A run should use idempotent steps and persist progress before waiting on human input. + +## 3.12 AgentOS runtime + +AgentOS is the durable supervisor and harness runtime for an active run. + +Recommended scope: + +- One AgentOS actor per active run or isolated workbox. +- Durable identity for the run environment. +- Harness session lifecycle. +- Event streaming. +- Permission requests. +- Lightweight filesystem and process coordination. +- Sleep and wake when safe. + +Do not use one giant actor per user or organization. + +The actor key should include tenant and work scope, for example: + +```text +org:{orgId}:project:{projectId}:work:{workUnitId}:run:{runId} +``` + +The durable work unit must survive destruction or replacement of its execution actor. + +## 3.13 Agent harness + +OpenCode is the initial coding harness. + +The architecture should support other ACP-compatible or adapted harnesses later. + +The harness owns: + +- Model interaction loop. +- Tool selection. +- Repository inspection. +- File editing. +- Shell requests. +- Local reasoning state. +- Session-level progress. + +The harness does not own: + +- Product work-unit state. +- Organization policy. +- Billing. +- Global memory. +- Project permissions. +- Long-term artifact retention. + +Prefer controlling OpenCode through AgentOS rather than exposing its standalone server directly to product clients. + +## 3.14 Full Linux sandbox + +A full sandbox is the compatibility and heavy-execution environment. + +It provides: + +- Repository checkout. +- Writable branch or worktree. +- Native binaries. +- Package installation. +- Language runtimes. +- Databases. +- Browser automation. +- Dev servers. +- Tests and builds. +- File watching when required. +- Preview processes. + +AgentOS should supervise and communicate with the sandbox through explicit adapters or bindings. + +Recommended division: + +```text +AgentOS +- durable run identity +- harness session +- approvals +- lightweight coordination + +Sandbox +- full repository filesystem +- native commands +- services +- browser +- tests +- builds +``` + +For known first-party templates, some work may run directly in the lighter environment. Imported arbitrary repositories should default to a full sandbox. + +## 3.15 Workbox + +A Workbox is the product-neutral internal term for the execution capsule beneath a run. + +A Workbox contains: + +- Repository checkout. +- Isolated branch. +- Runtime recipe. +- Harness configuration. +- Project skills. +- Temporary credentials. +- Running services. +- Preview endpoints. +- Test outputs. + +A Workbox is ephemeral or replaceable. The work unit is durable. + +Default isolation rule: + +> One writable checkout per active work unit or mutating run. + +Parallel read-only runs may share immutable snapshots. Parallel mutating runs should use separate branches and separate Workboxes. + +## 3.16 Managed or connected Git + +Git is the source history layer. + +Project creation modes: + +- Create from a managed template repository. +- Connect an external repository. +- Import and mirror an existing repository. +- Start with managed Git and add an external remote later. + +Identity model: + +- One Work OS user identity. +- Internal service identities for automation. +- Repository-scoped, short-lived credentials. +- No requirement for users to manage a second visible Git account. + +Branching model: + +```text +main +├── work/W-102/oauth-fix +├── work/W-103/team-invitations +└── work/W-104/pricing-copy +``` + +Git may remain hidden in the product surface, but the user must retain portability through export, clone access, patch download, or external remotes. + +## 3.17 Project templates + +Initial templates may include: + +- React web application. +- Hono service. +- Express API. +- Full-stack application. +- API-only service. +- Expo application. +- Monorepo starter. + +A template should define: + +- Source files. +- Runtime versions. +- Install command. +- Test command. +- Verification command. +- Development command. +- Service ports. +- Preview behavior. +- Project context prompts. +- Default policies. +- Agent skills. + +Templates should generate a reusable base snapshot after successful setup and verification. + +## 3.18 Project configuration files + +Recommended repository structure: + +```text +/ +├── README.md +├── AGENTS.md +├── product.md +├── design.md +├── tech.md +│ +├── .zopo/ +│ ├── project.yaml +│ ├── services.yaml +│ ├── policies.yaml +│ ├── lifecycle/ +│ │ ├── setup +│ │ ├── resume +│ │ ├── verify +│ │ └── preview +│ └── skills/ +│ ├── testing/ +│ │ └── SKILL.md +│ ├── reviewing/ +│ │ └── SKILL.md +│ └── deploying/ +│ └── SKILL.md +└── apps/ +``` + +Example `project.yaml`: + +```yaml +name: example-project +runtime: + template: react-hono + node: "24" + packageManager: pnpm + +commands: + install: pnpm install --frozen-lockfile + test: pnpm test + verify: pnpm run verify + dev: pnpm dev + +services: + web: + port: 3000 + api: + port: 4000 + +changes: + workflow: pull_request + baseBranch: main + +approvals: + pushBranch: automatic + createPullRequest: automatic + mergePullRequest: required + deployPreview: automatic + deployProduction: required +``` + +## 3.19 Executor integration gateway + +Executor acts as the shared integration and tool gateway for external systems. + +It may expose: + +- GitHub APIs. +- Slack. +- Linear. +- Intercom. +- Analytics. +- CRM. +- Cloud services. +- Internal APIs. +- Custom functions. + +Responsibilities: + +- Connection management. +- Tool catalog. +- Scoped authentication. +- Tool-level policies. +- Approval requirements. +- Auditable invocation. + +It should not own: + +- Shell execution. +- Repository filesystem operations. +- Work-unit state. +- Agent session state. +- Sandbox lifecycle. + +The Flow Agent may receive broader organization-level tools. OpenCode should receive only the project- and run-scoped tools needed for the current task. + +## 3.20 Model gateway + +All model calls should route through a model gateway. + +Responsibilities: + +- Provider credentials. +- Automatic model routing. +- Tenant attribution. +- Cost accounting. +- Budget enforcement. +- Rate limits. +- Retries and fallback. +- Prompt and response logging under policy. +- Redaction. +- Run-scoped credentials. + +The product should not expose model selection by default. + +A run token should be short-lived and scoped: + +```json +{ + "organization_id": "org_01...", + "project_id": "prj_01...", + "work_unit_id": "wrk_01...", + "run_id": "run_01...", + "model_classes": ["coding-standard", "coding-fast"], + "budget_usd": 8, + "expires_in_seconds": 3600 +} +``` + +## 3.21 Artifact storage + +Large and durable outputs belong in object storage, not actor state or relational rows. + +Artifact types include: + +- Patch. +- Commit bundle. +- Test report. +- Build log. +- Screenshot. +- Video. +- Preview snapshot. +- Research document. +- Review report. +- Generated file. + +Artifact metadata should include: + +- Tenant scope. +- Work-unit scope. +- Run scope. +- Type. +- Content hash. +- Producer. +- Source event. +- Retention policy. +- Access policy. + +## 3.22 Preview gateway + +Preview environments should be exposed through a controlled gateway rather than raw sandbox ports. + +Requirements: + +- Authenticated access. +- Project- and run-scoped routing. +- Short-lived URLs where appropriate. +- Service health. +- Automatic shutdown. +- Event emission when preview becomes ready or fails. +- Screenshot or browser verification integration. + +## 3.23 Observability and billing + +Every execution path should emit: + +- Logs. +- Metrics. +- Traces. +- Cost. +- Token use. +- Runtime duration. +- Tool calls. +- Network use. +- Artifact size. +- Retry count. +- User intervention count. + +Required correlation dimensions: + +```text +organization_id +project_id +work_unit_id +run_id +actor_id +session_id +sandbox_id +sequence +timestamp +``` + +The system should calculate cost per successful outcome, not merely cost per model request. + +--- + +## 4. Core execution flows + +## 4.1 Project onboarding + +```mermaid +sequenceDiagram + actor User + participant UI as Work OS UI + participant Project as Project Service + participant Git as Git Service + participant Template as Template Builder + participant Context as Context Service + participant Snapshot as Snapshot Service + + User->>UI: Create project + UI->>Project: Name, organization, template or repository + Project->>Git: Create, import, or connect repository + Git-->>Project: Repository identity + Project->>Template: Apply project template if selected + Template->>Git: Commit initial files + Project->>Context: Generate context-document drafts + Context-->>UI: Ask user to review product, design, and technical context + User->>UI: Confirm context + UI->>Git: Commit canonical project documents + Project->>Template: Run setup and verification + Template->>Snapshot: Create sanitized base snapshot + Snapshot-->>Project: Snapshot ready + Project-->>UI: Project active +``` + +## 4.2 Prompt to candidate work + +```mermaid +sequenceDiagram + actor User + participant UI as Composer + participant Conversation as Conversation Service + participant Flow as Flow Agent + participant Work as Work Graph + participant Realtime as Realtime Gateway + + User->>UI: Describe request or problem + UI->>Conversation: Persist message with scope + Conversation->>Flow: Publish extraction job + Flow->>Work: Search related work and sources + Flow->>Work: Create or update signal + alt Existing work matches + Flow->>Work: Attach signal and update understanding + else New outcome detected + Flow->>Work: Create candidate work + end + Work->>Realtime: Publish materialized update + Realtime-->>UI: Show updated or new card +``` + +## 4.3 Accepted work to verified pull request + +```mermaid +sequenceDiagram + actor User + participant UI as Work OS UI + participant Flow as Flow Agent + participant State as Work Graph + participant Scheduler as Scheduler + participant AgentOS as AgentOS Actor + participant Harness as OpenCode + participant Box as Workbox Sandbox + participant Git as Git Service + participant Artifact as Artifact Store + + User->>UI: Approve candidate and start work + UI->>State: Accept work unit + State->>Flow: Work unit ready + Flow->>State: Persist objective and acceptance criteria + Flow->>Scheduler: Create implementation run + Scheduler->>AgentOS: Provision run actor + AgentOS->>Box: Create isolated sandbox + Box->>Git: Clone repository and create work branch + AgentOS->>Harness: Start OpenCode session + Flow->>Harness: Send run context pack + + loop Execution + Harness->>Box: Inspect, edit, and execute + Harness-->>AgentOS: Stream events and requests + AgentOS->>State: Persist meaningful run events + State-->>UI: Update work card + end + + Harness->>Box: Run verification + Box->>Artifact: Upload reports and screenshots + Box->>Git: Commit and push branch + Flow->>Git: Create pull request + Flow->>State: Attach artifacts and move to Review + State-->>UI: Show PR, preview, evidence, and human action +``` + +## 4.4 Approval continuation + +```mermaid +sequenceDiagram + participant Harness as Agent Harness + participant AgentOS as AgentOS + participant Policy as Policy Engine + participant UI as Attention Queue + actor User + + Harness->>AgentOS: Request sensitive action + AgentOS->>Policy: Evaluate action and scope + alt Automatically allowed + Policy-->>AgentOS: Allow + else Requires human approval + Policy->>UI: Create approval request + UI-->>User: Show action, evidence, risk, and impact + User->>UI: Approve, modify, or reject + UI->>Policy: Persist decision + Policy-->>AgentOS: Resume with bounded permission + else Denied + Policy-->>AgentOS: Deny with reason + end +``` + +--- + +## 5. State machines + +Keep product, run, and environment state separate. + +## 5.1 Work-unit state + +```text +proposed +→ clarifying +→ ready +→ active +→ waiting | review | monitoring +→ done +``` + +Possible modifiers: + +- blocked. +- waiting_on_user. +- waiting_on_dependency. +- approval_required. +- autonomous. +- at_risk. +- scheduled. + +## 5.2 Run state + +```text +queued +→ provisioning +→ preparing +→ running +→ waiting_for_input | verifying +→ succeeded | failed | cancelled +``` + +## 5.3 Workbox state + +```text +creating +→ preparing +→ ready +→ busy +→ sleeping | waking +→ destroyed +``` + +The frontend should primarily expose work-unit state. Run state appears as operational detail. Workbox state is usually hidden except during debugging or delayed startup. + +--- + +## 6. Concurrency model + +Default rules: + +- One writable checkout per active mutating run. +- One branch per independently shippable work unit. +- Serialize mutating runs against the same branch. +- Permit parallel read-only analysis against immutable snapshots. +- Permit parallel child work on separate branches. +- Treat merge and integration as explicit controlled actions. + +Example: + +```text +Work Unit A → branch work/a → Workbox A +Work Unit B → branch work/b → Workbox B +Work Unit C → branch work/c → Workbox C +``` + +A work unit may use multiple runs: + +```text +research +→ implementation +→ automated review +→ verification +→ human review +``` + +Do not allow agents to share one writable working directory without deliberate coordination and conflict handling. + +--- + +## 7. Persistence and recovery + +The durable source of truth is outside transient agent processes. + +Persist after every meaningful step: + +- Work-unit state changes. +- Decisions. +- Approval requests. +- Agent summaries. +- Tool results required for audit. +- Repository commit or patch checkpoints. +- Artifact metadata. +- Verification results. + +Do not rely on: + +- A running shell process. +- In-memory harness state. +- Open sockets. +- An uncommitted working directory surviving indefinitely. + +Before waiting for human input: + +- Persist current findings. +- Save or commit relevant file changes. +- Upload important artifacts. +- Record the exact requested decision. +- Store resumable workflow state. + +All workflow steps should be idempotent or safely repeatable. + +--- + +## 8. Security model + +## 8.1 Trust boundaries + +Treat as untrusted: + +- Imported repositories. +- Repository instructions. +- External documents. +- Customer messages. +- MCP tools. +- Tool responses. +- Generated code. +- Agent-authored summaries. + +A model recommendation is not an authorization decision. + +## 8.2 Layered authorization + +A sensitive action requires all relevant layers to allow it: + +```text +Product policy +AND +Harness permission +AND +Runtime capability +AND +Scoped credential +``` + +The action path is: + +```text +Agent requests action +→ harness permission check +→ Work OS policy evaluation +→ human approval when required +→ runtime capability check +→ credential minting +→ action execution +→ provenance event +``` + +## 8.3 Workload identity + +Every run should receive a short-lived identity containing: + +- organization_id. +- project_id. +- work_unit_id. +- run_id. +- user or initiating principal. +- permitted capabilities. +- expiration. + +The Workbox exchanges this identity for scoped access to: + +- Git. +- Model gateway. +- Integration tools. +- Artifact storage. +- Preview gateway. +- Optional cloud environments. + +Avoid injecting long-lived organization credentials into sandboxes. + +## 8.4 Network policy + +Network access should be deny-by-default or allowlisted by run type. + +Examples: + +- Package registry access during setup. +- Repository host access. +- Model gateway access. +- Approved external APIs. +- No unrestricted production network access by default. + +## 8.5 Secrets + +Secrets should be: + +- Stored outside repositories and actor state. +- Scoped to organization and project. +- Minted or injected only when required. +- Short-lived where possible. +- Redacted from logs and transcripts. +- Rotatable without rebuilding projects. +- Audited when accessed. + +## 8.6 Data isolation + +Every storage query, event, artifact, context lookup, and runtime token must be tenant-scoped. + +Cross-organization portfolio views may aggregate summaries but must never provide one organization’s raw context to another organization’s agent run. + +## 8.7 Human approvals + +Approval should be required for actions such as: + +- Production deployment. +- Merging protected branches. +- Accessing sensitive production data. +- Sending external communications. +- Changing billing or financial state. +- Deleting data. +- Changing organization-level policy. + +Approval should be action-specific and expire after use or time. + +## 8.8 Auditability + +The system must retain: + +- Who initiated work. +- What context was provided. +- Which agent and model class performed the run. +- Which tools were called. +- What files changed. +- Which approvals were requested and granted. +- What artifacts were produced. +- What was published or merged. +- What outcome was observed. + +--- + +## 9. Scaling model + +Scale through many small, isolated actors and queued runs rather than long-lived per-user machines. + +## 9.1 Tenant scheduler + +Enforce: + +- Maximum concurrent runs per organization. +- Maximum concurrent runs per project. +- Priority classes. +- Fair scheduling. +- Subscription limits. +- Model budget. +- Sandbox budget. +- Retry limits. +- Runtime duration limits. + +## 9.2 Work queue + +Use explicit states: + +```text +accepted +→ queued +→ leased +→ running +→ completed +``` + +Leases should be idempotent and recoverable to prevent duplicate expensive execution. + +## 9.3 Resource limits + +Apply hard and soft limits for: + +- Tokens per run. +- Cost per run. +- Runtime duration. +- Tool calls. +- File count and repository size. +- Network bytes. +- Process count. +- Memory and CPU. +- Artifact size. +- Subagent depth. +- Repeated failure count. + +## 9.4 Artifact offloading + +Do not store large logs or binaries in actor state or database rows. Store them in object storage and retain references in the work graph. + +## 9.5 Snapshot strategy + +Use sanitized reusable snapshots for project setup acceleration. + +Snapshot layers may include: + +- Base operating environment. +- Language and toolchain layer. +- Template layer. +- Project dependency layer. + +Do not snapshot: + +- Long-lived credentials. +- User-specific secrets. +- Active tokens. +- Unreviewed production data. + +## 9.6 Multi-region considerations + +Keep control-plane relational consistency explicit. + +Potential strategy: + +- Organization home region. +- Region-local execution actors. +- Region-local artifact and cache placement. +- Global routing to the organization’s control plane. +- Explicit restrictions for data residency. + +Do not make multi-region execution an MVP requirement unless customer needs demand it. + +--- + +## 10. Better-T-Stack monorepo mapping + +Assuming an existing monorepo with `apps/web`, `apps/expo`, and shared packages, a possible structure is: + +```text +apps/ +├── web/ +├── expo/ +├── api/ +├── worker/ +├── agent-runtime/ +└── preview-gateway/ + +packages/ +├── db/ +├── auth/ +├── domain/ +├── api-contract/ +├── events/ +├── realtime/ +├── work-graph/ +├── conversation/ +├── flow-agent/ +├── context/ +├── policy/ +├── scheduler/ +├── integrations/ +├── model-gateway/ +├── git/ +├── artifacts/ +├── sandbox/ +├── agentos/ +├── opencode/ +├── observability/ +├── billing/ +├── ui/ +└── config/ +``` + +Suggested boundaries: + +### `packages/domain` + +Pure domain types and state transitions. + +### `packages/events` + +Event envelopes, schemas, reducers, and provenance utilities. + +### `packages/work-graph` + +Queries and commands for work entities and materialized views. + +### `packages/conversation` + +Message persistence, scopes, extraction jobs, and source links. + +### `packages/flow-agent` + +Orchestration logic, planning, and run coordination. + +### `packages/context` + +Canonical context loading, retrieval, and run context-pack construction. + +### `packages/policy` + +Policy evaluation and approval workflows. + +### `packages/scheduler` + +Queues, leases, quotas, workflows, retries, and cancellation. + +### `packages/agentos` + +AgentOS client, actor naming, session lifecycle, and event translation. + +### `packages/opencode` + +Harness configuration, session prompts, tool policy, and result normalization. + +### `packages/sandbox` + +Sandbox provider adapters, workspace lifecycle, commands, logs, and previews. + +### `packages/git` + +Repository provisioning, branches, commits, pushes, pull requests, and mirrors. + +### `packages/integrations` + +Executor connection management and tool scopes. + +### `packages/model-gateway` + +Provider routing, budgets, credentials, and cost attribution. + +--- + +## 11. API and command design + +Prefer domain commands over generic entity mutation. + +Examples: + +```text +CreateProject +ImportRepository +CreateWorkUnit +AcceptCandidate +AttachSignal +MergeCandidates +StartWork +UpdateRequirements +ApprovePlan +ResolveBlocker +RequestChanges +PauseRun +CancelRun +ApproveAction +RejectAction +ApproveMerge +ApproveDeployment +ReopenWorkUnit +``` + +Each command should: + +- Validate tenant scope. +- Validate current state. +- Be idempotent where practical. +- Emit one or more domain events. +- Avoid direct client control of infrastructure details. + +--- + +## 12. Event translation from harness to product + +Raw harness events should be preserved for audit but translated into human-meaningful product events. + +Examples: + +```text +Raw: tool_call bash "pnpm test" +Product: run.verification_started + +Raw: tool_result exit_code=0 +Product: run.test_suite_passed + +Raw: permission_request git_push +Product: approval.requested + +Raw: file_edit src/auth/callback.ts +Product: artifact.code_change_updated +``` + +The primary UI should not expose raw transcripts unless the user opens technical details. + +--- + +## 13. Initial implementation sequence + +## Phase 1: Durable product model + +- Organizations. +- Projects. +- Work units. +- Candidates. +- Runs. +- Artifacts. +- Conversation scopes. +- Event log. +- Card projections. + +## Phase 2: One complete coding loop + +- One template project. +- Managed Git. +- One sandbox provider. +- One AgentOS actor per run. +- OpenCode harness. +- Model gateway. +- Branch creation. +- Tests. +- Artifact upload. +- Pull request output. +- Human approval. + +## Phase 3: Context and memory + +- Canonical Markdown files. +- Context-pack construction. +- Retrieval index. +- Decision memory. +- Source provenance. + +## Phase 4: Autonomous discovery + +- Continuous signal ingestion. +- Candidate extraction. +- Duplicate detection. +- Existing work matching. +- Attention queue. + +## Phase 5: Additional integrations and workflows + +- External Git. +- Support. +- Team communication. +- Issue trackers. +- Analytics. +- Deployment and monitoring. + +--- + +## 14. MVP success criteria + +The first release should reliably demonstrate: + +```text +Prompt +→ candidate or work unit +→ clarified objective +→ isolated coding run +→ tested change +→ preview or evidence +→ pull request +→ human review +→ durable completed work card +``` + +The work unit must remain understandable and resumable even if the underlying harness session or Workbox is destroyed. + +--- + +## 15. Technical non-goals for the first release + +- Supporting every harness. +- Supporting every sandbox provider. +- Arbitrary multi-agent swarms. +- Full replacement of external Git providers. +- Multi-region active-active control plane. +- Unlimited imported repository compatibility. +- Automatic production deployment without approval. +- A generic low-code workflow builder. +- Exposing model selection and agent internals to users. + +--- + +## 16. Architectural principles + +1. **Durable work state must outlive execution environments.** +2. **Every execution path is tenant-scoped.** +3. **Use one writable checkout per mutating unit of work.** +4. **Persist events before projecting summaries.** +5. **Treat agent outputs as claims with provenance, not unquestioned truth.** +6. **Separate product policy, harness permission, and runtime capability.** +7. **Use short-lived credentials and explicit workload identity.** +8. **Keep harnesses, models, sandboxes, and Git providers replaceable.** +9. **Hide infrastructure state from the product surface unless actionable.** +10. **Measure successful outcomes and human attention, not merely agent activity.** diff --git a/bun.lock b/bun.lock index e142821..68efa28 100644 --- a/bun.lock +++ b/bun.lock @@ -150,14 +150,21 @@ "@code/backend": "workspace:*", "@code/env": "workspace:*", "@flue/runtime": "latest", +<<<<<<< Updated upstream "@rivet-dev/agentos-core": "catalog:", "convex": "catalog:", "hono": "4.12.30", +======= + "@rivet-dev/agentos-core": "^0.2.10", + "convex": "catalog:", + "hono": "^4.12.30", +>>>>>>> Stashed changes "valibot": "^1.4.2", }, "devDependencies": { "@code/config": "workspace:*", "@flue/cli": "latest", +<<<<<<< Updated upstream "@types/bun": "catalog:", "typescript": "catalog:", }, @@ -188,6 +195,10 @@ "typescript": "catalog:", "vite": "catalog:", "vitest": "catalog:", +======= + "@types/bun": "latest", + "typescript": "^6", +>>>>>>> Stashed changes }, }, "packages/backend": { @@ -328,6 +339,11 @@ "@agentos-software/sed": ["@agentos-software/sed@0.3.4", "", {}, "sha512-J10nZnZmme2SvXK5WMK2unQlOVncMQVUCS20GZB579a2gNoayLJYHGvfJ9a4+42wOHgDKL1u74byWlydCkEyOQ=="], +<<<<<<< Updated upstream +======= + "@agentos-software/sed": ["@agentos-software/sed@0.3.4", "", {}, "sha512-J10nZnZmme2SvXK5WMK2unQlOVncMQVUCS20GZB579a2gNoayLJYHGvfJ9a4+42wOHgDKL1u74byWlydCkEyOQ=="], + +>>>>>>> Stashed changes "@agentos-software/tar": ["@agentos-software/tar@0.3.4", "", {}, "sha512-/SSqfgS5xOufvulsz5kVDTCFxpDy+5s7Og1iJe9krjU7Jvtgnp9TpPaJnSr721h6uY6tsWHcs3u8E457EwSkNw=="], "@alloc/quick-lru": ["@alloc/quick-lru@5.2.0", "", {}, "sha512-UrcABB+4bUrFABwbluTIBErXwvbsU/V7TZWfmbgJfbkwiBuziS9gxdODUyuiecfdGQ85jglMW6juS3+z5TsKLw=="], @@ -1216,7 +1232,11 @@ "@rivet-dev/agent-os-core": ["@rivet-dev/agent-os-core@0.1.1", "", { "dependencies": { "@rivet-dev/agent-os-posix": "0.1.0", "@rivet-dev/agent-os-python": "0.1.0", "@secure-exec/core": "^0.2.1", "@secure-exec/nodejs": "^0.2.1", "@secure-exec/v8": "^0.2.1", "croner": "^10.0.1", "long-timeout": "^0.1.1", "secure-exec": "^0.2.1" } }, "sha512-Uw5jr+gUXDY7TDUFqlypjGe1BD2KL9kTHPNo/f1iNS1R+l9IWuvT+FF/MXsLOEkc3fB06OPVu2ZvUuNwp9MpLQ=="], +<<<<<<< Updated upstream "@rivet-dev/agent-os-posix": ["@rivet-dev/agent-os-posix@0.1.0", "", { "dependencies": { "@secure-exec/core": "^0.2.1" } }, "sha512-NIrI7cCb9x6jdmzRPPx7dAeXoTF/YCqf93ydEzYFA2zshIelLW9Rp5KtgP/2hM6fP0ly4+vVnOeavxJW0wYtcA=="], +======= + "@rivet-dev/agentos-core": ["@rivet-dev/agentos-core@0.2.10", "", { "dependencies": { "@agentclientprotocol/sdk": "0.16.1", "@agentos-software/claude-code": "0.2.7", "@agentos-software/codex-cli": "0.3.4", "@agentos-software/common": "0.2.10", "@agentos-software/manifest": "0.2.10", "@agentos-software/opencode": "0.2.7", "@agentos-software/pi": "0.2.7", "@aws-sdk/client-s3": "^3.1019.0", "@rivet-dev/agentos-runtime-core": "0.2.10", "@rivet-dev/agentos-sidecar": "0.2.10", "@rivetkit/bare-ts": "^0.6.2", "@xterm/headless": "^6.0.0", "better-sqlite3": "^12.8.0", "croner": "^10.0.1", "googleapis": "^144.0.0", "isolated-vm": "^6.0.0", "long-timeout": "^0.1.1", "minimatch": "^10.2.4", "zod": "^4.1.11", "zod-to-json-schema": "^3.25.2" } }, "sha512-0UMQgBFOmMtiZ0UhQ3cJei44tRmY9VzTpkJh4a+g0HWjAz5thUH2OCYtmF+tGNU8qzHhyN9hBFwT744YMRV/Dg=="], +>>>>>>> Stashed changes "@rivet-dev/agent-os-python": ["@rivet-dev/agent-os-python@0.1.0", "", { "dependencies": { "@secure-exec/core": "^0.2.1", "pyodide": "^0.28.3" } }, "sha512-1tH1beMf1ceSpicQKwN/a6h+NmJrmfuT4GStiRDZmvN/UWfZhkxuy7HR5VPTQpE/feUZJ01FdtBS3Em/Qoxb2Q=="], @@ -1226,6 +1246,28 @@ "@rivet-dev/agentos-runtime-core": ["@rivet-dev/agentos-runtime-core@0.2.10", "", { "dependencies": { "@rivet-dev/agentos-runtime-sidecar": "0.2.10", "@rivetkit/bare-ts": "^0.6.2", "zod": "^4.1.11" } }, "sha512-qMmWhDZ/IWL0QOKnASl1STHwRQaDknX34DTX1p+fCjcWbf2QD+ScQMTLdll52oyhQl8KhXn+Tlyhp+XTdqaySQ=="], +<<<<<<< Updated upstream + "@rivet-dev/agentos-runtime-sidecar": ["@rivet-dev/agentos-runtime-sidecar@0.2.10", "", { "optionalDependencies": { "@rivet-dev/agentos-runtime-sidecar-darwin-arm64": "0.2.10", "@rivet-dev/agentos-runtime-sidecar-darwin-x64": "0.2.10", "@rivet-dev/agentos-runtime-sidecar-linux-arm64-gnu": "0.2.10", "@rivet-dev/agentos-runtime-sidecar-linux-x64-gnu": "0.2.10" } }, "sha512-v2KXHTTQYHdMpNFhBt3/wCyKajwxq9o4jKLYpaa9mYiaBdHfORuBaDI9e3WDGEly7HCIEWNnwvkNMvoQoHnXnQ=="], + + "@rivet-dev/agentos-runtime-sidecar-darwin-arm64": ["@rivet-dev/agentos-runtime-sidecar-darwin-arm64@0.2.10", "", { "os": "darwin", "cpu": "arm64" }, "sha512-PJ5rJZmgpS/EX9Zn1UA6Z5Ol0Y31UJKfD7Fisdqy7hlJuxhQVS9cVFrp3bud2og9s3n32riEYTx1mUE1PVQKZA=="], + + "@rivet-dev/agentos-runtime-sidecar-darwin-x64": ["@rivet-dev/agentos-runtime-sidecar-darwin-x64@0.2.10", "", { "os": "darwin", "cpu": "x64" }, "sha512-+C4gEE7/pT36fclYqdUYt6bMUj6CsDDZ+2Kxuej57/q06cSa9W5Od2zIO4wxZbI6g0EoN5zVJ8qXv+jSOtTLbg=="], + + "@rivet-dev/agentos-runtime-sidecar-linux-arm64-gnu": ["@rivet-dev/agentos-runtime-sidecar-linux-arm64-gnu@0.2.10", "", { "os": "linux", "cpu": "arm64" }, "sha512-BSs/LkKkNxvNBD9qEmxPWHmdHQokNGkGS3dcI3LTY4D6Sgat1Vun1OQ53v1HQSGf/TuAfgYOzbQPikvOU3zkmQ=="], + + "@rivet-dev/agentos-runtime-sidecar-linux-x64-gnu": ["@rivet-dev/agentos-runtime-sidecar-linux-x64-gnu@0.2.10", "", { "os": "linux", "cpu": "x64" }, "sha512-IIM0ILGdPNjettgBVOXvrNTICggo/xNtKO0V3kM7XJiQ4DkQQkjA1/Y0JBdLvsigt7HAcEJ38zQ3ahl+HOXK8w=="], + + "@rivet-dev/agentos-sidecar": ["@rivet-dev/agentos-sidecar@0.2.10", "", { "optionalDependencies": { "@rivet-dev/agentos-sidecar-darwin-arm64": "0.2.10", "@rivet-dev/agentos-sidecar-darwin-x64": "0.2.10", "@rivet-dev/agentos-sidecar-linux-arm64-gnu": "0.2.10", "@rivet-dev/agentos-sidecar-linux-x64-gnu": "0.2.10" } }, "sha512-3bq7k/OrtMffUT+aDSeXPIEDEaJLbPXzQ5oUqnjsU+6Hsmvvf+nAl/zTvHyQOMmriQiQ1BPMPqgNyXAc5BrV3w=="], + + "@rivet-dev/agentos-sidecar-darwin-arm64": ["@rivet-dev/agentos-sidecar-darwin-arm64@0.2.10", "", { "os": "darwin", "cpu": "arm64" }, "sha512-q+54J8WLa/Diyn5H+TVZwIHt4kVFCBkwtco5DjUmFmG6y5ozzPl6MM0vVzIx6iNTzhWiYOFLz5PybICmy6j7BQ=="], + + "@rivet-dev/agentos-sidecar-darwin-x64": ["@rivet-dev/agentos-sidecar-darwin-x64@0.2.10", "", { "os": "darwin", "cpu": "x64" }, "sha512-Q0rAxtGjddpDcaB9keicukuExtIiynwX+DqVRG6hWjki0PSYqFqqrNFCzPiUswWf0u5Pakq1iBM+RgNu19PxZA=="], + + "@rivet-dev/agentos-sidecar-linux-arm64-gnu": ["@rivet-dev/agentos-sidecar-linux-arm64-gnu@0.2.10", "", { "os": "linux", "cpu": "arm64" }, "sha512-FVgsnPczeT4oMoiUTrOfadAtDGoHhd30lrAU2p/xxyeCOhHAsZt1h0xo2oCteLmZ78DJm3rLcsR+4zhY6AhtOw=="], + +======= + "@rivet-dev/agentos-runtime-core": ["@rivet-dev/agentos-runtime-core@0.2.10", "", { "dependencies": { "@rivet-dev/agentos-runtime-sidecar": "0.2.10", "@rivetkit/bare-ts": "^0.6.2", "zod": "^4.1.11" } }, "sha512-qMmWhDZ/IWL0QOKnASl1STHwRQaDknX34DTX1p+fCjcWbf2QD+ScQMTLdll52oyhQl8KhXn+Tlyhp+XTdqaySQ=="], + "@rivet-dev/agentos-runtime-sidecar": ["@rivet-dev/agentos-runtime-sidecar@0.2.10", "", { "optionalDependencies": { "@rivet-dev/agentos-runtime-sidecar-darwin-arm64": "0.2.10", "@rivet-dev/agentos-runtime-sidecar-darwin-x64": "0.2.10", "@rivet-dev/agentos-runtime-sidecar-linux-arm64-gnu": "0.2.10", "@rivet-dev/agentos-runtime-sidecar-linux-x64-gnu": "0.2.10" } }, "sha512-v2KXHTTQYHdMpNFhBt3/wCyKajwxq9o4jKLYpaa9mYiaBdHfORuBaDI9e3WDGEly7HCIEWNnwvkNMvoQoHnXnQ=="], "@rivet-dev/agentos-runtime-sidecar-darwin-arm64": ["@rivet-dev/agentos-runtime-sidecar-darwin-arm64@0.2.10", "", { "os": "darwin", "cpu": "arm64" }, "sha512-PJ5rJZmgpS/EX9Zn1UA6Z5Ol0Y31UJKfD7Fisdqy7hlJuxhQVS9cVFrp3bud2og9s3n32riEYTx1mUE1PVQKZA=="], @@ -1244,6 +1286,7 @@ "@rivet-dev/agentos-sidecar-linux-arm64-gnu": ["@rivet-dev/agentos-sidecar-linux-arm64-gnu@0.2.10", "", { "os": "linux", "cpu": "arm64" }, "sha512-FVgsnPczeT4oMoiUTrOfadAtDGoHhd30lrAU2p/xxyeCOhHAsZt1h0xo2oCteLmZ78DJm3rLcsR+4zhY6AhtOw=="], +>>>>>>> Stashed changes "@rivet-dev/agentos-sidecar-linux-x64-gnu": ["@rivet-dev/agentos-sidecar-linux-x64-gnu@0.2.10", "", { "os": "linux", "cpu": "x64" }, "sha512-WXKLIeZJvOo2Kxw2wPmPNc7QWM0lq69Xt/Yy2W86gYKORAFPVJ9GVag85ywP3LrjIW1oEDwzqrvMp3PGVkvVXg=="], "@rivetkit/bare-ts": ["@rivetkit/bare-ts@0.6.2", "", {}, "sha512-3qndQUQXLdwafMEqfhz24hUtDPcsf1Bu3q52Kb8MqeH8JUh3h6R4HYW3ZJXiQsLcyYyFM68PuIwlLRlg1xDEpg=="], @@ -2373,8 +2416,11 @@ "gaxios": ["gaxios@6.7.1", "", { "dependencies": { "extend": "^3.0.2", "https-proxy-agent": "^7.0.1", "is-stream": "^2.0.0", "node-fetch": "^2.6.9", "uuid": "^9.0.1" } }, "sha512-LDODD4TMYx7XXdpwxAVRAIAuB0bzv0s+ywFonY46k126qzQHT9ygyoa9tncmOiQmmDrik65UYsEkv3lbfqQ3yQ=="], "gcp-metadata": ["gcp-metadata@6.1.1", "", { "dependencies": { "gaxios": "^6.1.1", "google-logging-utils": "^0.0.2", "json-bigint": "^1.0.0" } }, "sha512-a4tiq7E0/5fTjxPAaH4jpjkSv/uCaU2p5KC6HVGrvl0cDjA8iBZv4vv1gyzlmK0ZUKqwpOyQMKzZQe3lTit77A=="], +<<<<<<< Updated upstream "generator-function": ["generator-function@2.0.1", "", {}, "sha512-SFdFmIJi+ybC0vjlHN0ZGVGHc3lgE0DxPAT0djjVg+kjOnSqclqmj0KQ7ykTOLP6YxoqOvuAODGdcHJn+43q3g=="], +======= +>>>>>>> Stashed changes "gensync": ["gensync@1.0.0-beta.2", "", {}, "sha512-3hN7NaskYvMDLQY55gnW3NQ+mesEAepTqlg+VEbj7zzqEMBVNhzcGYYeqFo/TlYz6eQiFcp1HcsCZO+nGgS8zg=="], @@ -3854,8 +3900,11 @@ "@expo/xcpretty/chalk": ["chalk@4.1.2", "", { "dependencies": { "ansi-styles": "^4.1.0", "supports-color": "^7.1.0" } }, "sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA=="], +<<<<<<< Updated upstream "@flue/runtime/hono": ["hono@4.12.31", "", {}, "sha512-zJIHFrl6bq3RDd2YusFNCDlM8qUprxKswyi/OPzPyzKDdyBXDqWx8bZlZ7R+saTdSTatUmb3O7K4SspGPaEOQg=="], +======= +>>>>>>> Stashed changes "@google/genai/google-auth-library": ["google-auth-library@10.9.0", "", { "dependencies": { "base64-js": "^1.3.0", "ecdsa-sig-formatter": "^1.0.11", "gaxios": "^7.1.4", "gcp-metadata": "8.1.2", "google-logging-utils": "1.1.3", "jws": "^4.0.0" } }, "sha512-xtvUqvINPhTaBm7nXqlYPcrMHJPm1lCNdSovxnKKhTm+4JsvQ+KGVYJViLoH9Yxu8w+T0Qv5HubzYT9BLrppJg=="], "@google/genai/p-retry": ["p-retry@4.6.2", "", { "dependencies": { "@types/retry": "0.12.0", "retry": "^0.13.1" } }, "sha512-312Id396EbJdvRONlngUx0NydfrIQ5lsYu0znKVUzVvArzEIt08V1qhtyESbGVd1FGX7UKtiFp5uwKZdM8wIuQ=="], @@ -3864,6 +3913,8 @@ "@jest/schemas/@sinclair/typebox": ["@sinclair/typebox@0.27.12", "", {}, "sha512-hhyNJ+nbR6ZR7pToHvllEFun9TL0sbL+tk/ON75lo+Xas054uez98qRbsuNt7MBCyZKK4+8Yli/OAGZhmfBZ/g=="], + "@jest/schemas/@sinclair/typebox": ["@sinclair/typebox@0.27.12", "", {}, "sha512-hhyNJ+nbR6ZR7pToHvllEFun9TL0sbL+tk/ON75lo+Xas054uez98qRbsuNt7MBCyZKK4+8Yli/OAGZhmfBZ/g=="], + "@jest/types/@types/node": ["@types/node@26.1.1", "", { "dependencies": { "undici-types": "~8.3.0" } }, "sha512-nxAkRSVkN1Y0JC1W8ky/fTfkGsMmcrRsbx+3XoZE+rMOX71kLYTV7fLXpqud1GpbpP5TuffXFqfX7fH2GgZREw=="], "@jest/types/chalk": ["chalk@4.1.2", "", { "dependencies": { "ansi-styles": "^4.1.0", "supports-color": "^7.1.0" } }, "sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA=="], @@ -3876,8 +3927,11 @@ "@mariozechner/pi-ai/@mistralai/mistralai": ["@mistralai/mistralai@1.14.1", "", { "dependencies": { "ws": "^8.18.0", "zod": "^3.25.0 || ^4.0.0", "zod-to-json-schema": "^3.24.1" } }, "sha512-IiLmmZFCCTReQgPAT33r7KQ1nYo5JPdvGkrkZqA8qQ2qB1GHgs5LoP5K2ICyrjnpw2n8oSxMM/VP+liiKcGNlQ=="], +<<<<<<< Updated upstream "@mariozechner/pi-coding-agent/ignore": ["ignore@7.0.6", "", {}, "sha512-BAg6QkE8W+TuQLrrw0Ugr7HegXduRuuj8/ti2kSOc+jz1dmx8/WNcjr6XGnq5YpDWxFwwaavqD0+jIUOKelTsw=="], +======= +>>>>>>> Stashed changes "@mariozechner/pi-coding-agent/marked": ["marked@15.0.12", "", { "bin": { "marked": "bin/marked.js" } }, "sha512-8dD6FusOQSrpv9Z1rdNMdlSgQOIP880DHqnohobOmYLElGEqAL/JvxvuxZO16r4HtjTlfPRDC1hbvxC9dPN2nA=="], "@mariozechner/pi-coding-agent/strip-ansi": ["strip-ansi@7.2.0", "", { "dependencies": { "ansi-regex": "^6.2.2" } }, "sha512-yDPMNjp4WyfYBkHnjIRLfca1i6KMyGCtsVgoKe/z1+6vukgaENdgGBZt+ZmKPc4gavvEZ5OgHfHdrazhgNyG7w=="], @@ -3900,7 +3954,15 @@ "@react-router/dev/react-refresh": ["react-refresh@0.18.0", "", {}, "sha512-QgT5//D3jfjJb6Gsjxv0Slpj23ip+HtOpnNgnb2S5zU3CB26G/IDPGoy4RJB42wzFE46DRsstbW6tKHoKbhAxw=="], +<<<<<<< Updated upstream "@rivet-dev/agentos/rivetkit": ["rivetkit@2.3.7", "", { "dependencies": { "@hono/zod-openapi": "^1.1.5", "@rivet-dev/agent-os-core": "^0.1.1", "@rivetkit/bare-ts": "^0.6.2", "@rivetkit/engine-cli": "2.3.7", "@rivetkit/engine-envoy-protocol": "2.3.7", "@rivetkit/on-change": "6.0.1", "@rivetkit/rivetkit-napi": "2.3.7", "@rivetkit/rivetkit-wasm": "2.3.7", "@rivetkit/traces": "2.3.7", "@rivetkit/virtual-websocket": "2.3.7", "@rivetkit/workflow-engine": "2.3.7", "cbor-x": "^1.6.0", "drizzle-orm": "^0.44.2", "hono": "^4.7.0", "invariant": "^2.2.4", "p-retry": "^6.2.1", "pino": "^9.5.0", "uuid": "^12.0.0", "vbare": "^0.0.4", "zod": "^4.1.0" }, "peerDependencies": { "drizzle-kit": "^0.31.2", "eventsource": "^4.0.0", "ws": "^8.0.0" }, "optionalPeers": ["drizzle-kit", "eventsource", "ws"] }, "sha512-V2IWlXq9SRLJWrcYVa8WUftELCpbdsBVWZIqz2WQjhhzRK9Aan65RfMoZVx62A9k8HuIO6MH1nAPLhOuk1xePQ=="], +======= + "@rivet-dev/agentos/@agentos-software/common": ["@agentos-software/common@0.2.7", "", { "dependencies": { "@agentos-software/coreutils": "0.3.3", "@agentos-software/diffutils": "0.3.3", "@agentos-software/findutils": "0.3.3", "@agentos-software/gawk": "0.3.3", "@agentos-software/grep": "0.3.3", "@agentos-software/gzip": "0.3.3", "@agentos-software/sed": "0.3.3", "@agentos-software/tar": "0.3.3" } }, "sha512-eM5znR9qOaDIEsCBtzxzAfxgynq7ntNyk+lchHF7OUv7Cenbq4XGhCbA1T2dbl45G3/2Wz3+21QM0sv+797lvA=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-core": ["@rivet-dev/agentos-core@0.2.7", "", { "dependencies": { "@agentos-software/claude-code": "0.2.7", "@agentos-software/codex-cli": "0.3.3", "@agentos-software/common": "0.2.7", "@agentos-software/manifest": "0.2.7", "@agentos-software/opencode": "0.2.7", "@agentos-software/pi": "0.2.7", "@agentos-software/pi-cli": "0.2.7", "@aws-sdk/client-s3": "^3.1019.0", "@rivet-dev/agentos-runtime-core": "0.2.7", "@rivet-dev/agentos-sidecar": "0.2.7", "@rivetkit/bare-ts": "^0.6.2", "@xterm/headless": "^6.0.0", "better-sqlite3": "^12.8.0", "croner": "^10.0.1", "googleapis": "^144.0.0", "isolated-vm": "^6.0.0", "long-timeout": "^0.1.1", "minimatch": "^10.2.4", "zod": "^4.1.11", "zod-to-json-schema": "^3.25.2" } }, "sha512-7KC+eCo23lwaCYi+PoD8VxSg+BT46GesWFsAJBgTksKgOX2XOvDh3QKGKhNUU8ywwwtG4z3QpuRXe9kauXi6Zg=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-sidecar": ["@rivet-dev/agentos-sidecar@0.2.7", "", { "optionalDependencies": { "@rivet-dev/agentos-sidecar-darwin-arm64": "0.2.7", "@rivet-dev/agentos-sidecar-darwin-x64": "0.2.7", "@rivet-dev/agentos-sidecar-linux-arm64-gnu": "0.2.7", "@rivet-dev/agentos-sidecar-linux-x64-gnu": "0.2.7" } }, "sha512-mui+hg8uWF3mjubp6YfpTW21TAqB+ZpA/VTSsKjngEw774oBkuvpY+eycxRbsxZIM4RMzl0EdHgCt8fFTGNxOQ=="], +>>>>>>> Stashed changes "@rivetkit/framework-base/@tanstack/store": ["@tanstack/store@0.7.7", "", {}, "sha512-xa6pTan1bcaqYDS9BDpSiS63qa6EoDkPN9RsRaxHuDdVDNntzq3xNwR5YKTU/V3SkSyC9T4YVOPh2zRQN0nhIQ=="], @@ -4050,12 +4112,19 @@ "fbjs/promise": ["promise@7.3.1", "", { "dependencies": { "asap": "~2.0.3" } }, "sha512-nolQXZ/4L+bP/UGlkfaIujX9BKxGwmQ9OT4mOt5yvy8iK1h3wqTEJCijzGANTCCl9nWjY41juyAn2K3Q1hLLTg=="], +<<<<<<< Updated upstream "fetch-blob/web-streams-polyfill": ["web-streams-polyfill@3.3.3", "", {}, "sha512-d2JWLCivmZYTSIoge9MsgFCZrt571BikcWGYkjC1khllbTeDlGqZ2D8vD8E/lJa8WGWbb7Plm8/XJYV7IJHZZw=="], "gaxios/is-stream": ["is-stream@2.0.1", "", {}, "sha512-hFoiJiTl63nn+kstHGBtewWSKnQLpyb155KHheA1l39uvtO9nWIop1p3udqPcUd/xbF1VLMO4n7OI6p7RbngDg=="], "gaxios/uuid": ["uuid@9.0.1", "", { "bin": { "uuid": "dist/bin/uuid" } }, "sha512-b+1eJOlsR9K8HJpow9Ok3fiWOWSIcIzXodvv0rQjVoOVNpWMpxf1wZNpt4y9h10odCNrqnYp1OBzRktckBe3sA=="], +======= + "gaxios/is-stream": ["is-stream@2.0.1", "", {}, "sha512-hFoiJiTl63nn+kstHGBtewWSKnQLpyb155KHheA1l39uvtO9nWIop1p3udqPcUd/xbF1VLMO4n7OI6p7RbngDg=="], + + "gaxios/uuid": ["uuid@9.0.1", "", { "bin": { "uuid": "dist/bin/uuid" } }, "sha512-b+1eJOlsR9K8HJpow9Ok3fiWOWSIcIzXodvv0rQjVoOVNpWMpxf1wZNpt4y9h10odCNrqnYp1OBzRktckBe3sA=="], + +>>>>>>> Stashed changes "gcp-metadata/google-logging-utils": ["google-logging-utils@0.0.2", "", {}, "sha512-NEgUnEcBiP5HrPzufUkBzJOD/Sxsco3rLNo1F1TNf7ieU8ryUzBhqba8r756CjLX7rn3fHl6iLEwPYuqpoKgQQ=="], "googleapis-common/uuid": ["uuid@9.0.1", "", { "bin": { "uuid": "dist/bin/uuid" } }, "sha512-b+1eJOlsR9K8HJpow9Ok3fiWOWSIcIzXodvv0rQjVoOVNpWMpxf1wZNpt4y9h10odCNrqnYp1OBzRktckBe3sA=="], @@ -4116,8 +4185,11 @@ "native/react-dom": ["react-dom@19.2.3", "", { "dependencies": { "scheduler": "^0.27.0" }, "peerDependencies": { "react": "^19.2.3" } }, "sha512-yELu4WmLPw5Mr/lmeEpox5rw3RETacE++JgHqQzd2dg+YbJuat3jH4ingc+WPZhxaoFzdv9y33G+F7Nl5O0GBg=="], +<<<<<<< Updated upstream "node-stdlib-browser/punycode": ["punycode@1.4.1", "", {}, "sha512-jmYNElW7yvO7TV33CjSmvSiE2yco3bV2czu/OzDKdMNVZQWfxCblURLhf+47syQRBntjfLdd/H0egrzIG+oaFQ=="], +======= +>>>>>>> Stashed changes "npm-package-arg/hosted-git-info": ["hosted-git-info@7.0.2", "", { "dependencies": { "lru-cache": "^10.0.1" } }, "sha512-puUZAUKT5m8Zzvs72XWy3HtvVbTWljRE66cP60bxJzAqf2DgICo7lYTY2IHUmLnNpjYvw5bvmoHvPc0QO2a62w=="], "npm-package-arg/validate-npm-package-name": ["validate-npm-package-name@5.0.1", "", {}, "sha512-OljLrQ9SQdOUqTaQxqL5dEfZWrXExyyWsozYlAWFawPVNuD83igl7uJD2RTkNMbniIYgt8l81eCJGIdQF7avLQ=="], @@ -4354,9 +4426,13 @@ "@jest/types/chalk/supports-color": ["supports-color@7.2.0", "", { "dependencies": { "has-flag": "^4.0.0" } }, "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw=="], +<<<<<<< Updated upstream "@mariozechner/pi-ai/@aws-sdk/client-bedrock-runtime/@aws-sdk/token-providers": ["@aws-sdk/token-providers@3.1093.0", "", { "dependencies": { "@aws-sdk/core": "^3.976.0", "@aws-sdk/nested-clients": "^3.997.34", "@aws-sdk/types": "^3.974.2", "@smithy/core": "^3.29.4", "@smithy/types": "^4.16.1", "tslib": "^2.6.2" } }, "sha512-0TOm0RAnnsgV3eaG/xh/PlMxtmpv8hvdAjVReQvmOMhBgIKdYuc3Iz318GvnDNNgf3pUoV5zUaLVeGz4jp3shw=="], "@mariozechner/pi-ai/@aws-sdk/client-bedrock-runtime/@smithy/node-http-handler": ["@smithy/node-http-handler@4.9.9", "", { "dependencies": { "@smithy/core": "^3.29.7", "@smithy/types": "^4.16.1", "tslib": "^2.6.2" } }, "sha512-xVBZ3hptB99iNO9XyWqEhC7KD9bP9UPXhuy3h5Y2ItCfBv160D9IIC/Fmmp3EbnWwit4C+KVqlSE+E29Nk/pPg=="], +======= + "@react-native/codegen/yargs/cliui": ["cliui@8.0.1", "", { "dependencies": { "string-width": "^4.2.0", "strip-ansi": "^6.0.1", "wrap-ansi": "^7.0.0" } }, "sha512-BSeNnyus75C4//NQ9gQt1/csTXyo/8Sb+afLAkzAptFuMsod9HFokGNudZpi/oQV73hnVK+sR+5PVRMd+Dr7YQ=="], +>>>>>>> Stashed changes "@mariozechner/pi-ai/@mistralai/mistralai/ws": ["ws@8.21.1", "", { "peerDependencies": { "bufferutil": "^4.0.1", "utf-8-validate": ">=5.0.2" }, "optionalPeers": ["bufferutil", "utf-8-validate"] }, "sha512-+0NTnW77fFN/DjQi6k/Sq/Yvk4Sgajw7urW8V+asjXnRgDs9gyGkdb7EzgfhA4goXsRIZKE28fzIXBHEzhuiWw=="], @@ -4398,6 +4474,36 @@ "@rivetkit/framework-base/rivetkit/uuid": ["uuid@12.0.1", "", { "bin": { "uuid": "dist/bin/uuid" } }, "sha512-9obBF8sMIHJWNQaO6IGOG8giGa/jUpKX34bz6o4whVs8M0WAvhID2tNxYp6A2XEBJPuZSX8wsS/6TEKfIDc+nw=="], + "@rivet-dev/agentos/@agentos-software/common/@agentos-software/coreutils": ["@agentos-software/coreutils@0.3.3", "", {}, "sha512-uzBD6Q5z+ACn29CMNMSnA+nUzITbTosuOe6Hr/o5ylUpoxODbz6ziAwZ5Cr1XAgF//Qqz7HfQfnogf4zcb+Gvg=="], + + "@rivet-dev/agentos/@agentos-software/common/@agentos-software/diffutils": ["@agentos-software/diffutils@0.3.3", "", {}, "sha512-aaTMx3jWrTn18OxLk0g4nb3MgkLHjXyqlz5BQ3YlRj7hNuRT+hOPnzcSf8zP+pXFR+SGf7a98M2kSNV/ucfyDw=="], + + "@rivet-dev/agentos/@agentos-software/common/@agentos-software/findutils": ["@agentos-software/findutils@0.3.3", "", {}, "sha512-CrtFrmG2o+z0gaxtQBJw4wWGF7TxKq5ukxVFkf2/LxxsdZBc2F04MT6FNY3VMKf4Cq5kFvh7/ZRkMdg2yHAMvA=="], + + "@rivet-dev/agentos/@agentos-software/common/@agentos-software/gawk": ["@agentos-software/gawk@0.3.3", "", {}, "sha512-iHDeJ6rsGxijBQMmqH1w6bQ2+sWrC1f9OqNvUItHOZk85KFmg9a3ueyy0krq9pZRuZe+fU5yEhuUg7ovNqZ9NQ=="], + + "@rivet-dev/agentos/@agentos-software/common/@agentos-software/grep": ["@agentos-software/grep@0.3.3", "", {}, "sha512-jV49HWFJcEGjHBPk37EnisrdKwNfeZ+d+TA6LpAuDKRwFmj/2xc3rGVCTvKIxdZUKYuffu9NI9xgxJ0iKiUU2w=="], + + "@rivet-dev/agentos/@agentos-software/common/@agentos-software/gzip": ["@agentos-software/gzip@0.3.3", "", {}, "sha512-Jbmsu7trAhnnWvT9qlry/hETa5EOlUwdcYHtsyV9W2OQvMc3tOeLy3zwF8nWNuZ3/g1veRenRkK1ZgkqsDZpiw=="], + + "@rivet-dev/agentos/@agentos-software/common/@agentos-software/sed": ["@agentos-software/sed@0.3.3", "", {}, "sha512-cVNTD9VzodpJ+Kn/xqHo/AcUUkpPSuF9A/0jIqFkDNF24alwNG8ndVLwgFWMP+0mSo68HZumbjjnMQWE3NjRSw=="], + + "@rivet-dev/agentos/@agentos-software/common/@agentos-software/tar": ["@agentos-software/tar@0.3.3", "", {}, "sha512-pmYVIn3XQEKVbfKhms7bEpsGR7YXqaLXtglIHmnhyUwLZhdyerrEkO+VgpC8zuWMeYfmTsstEgpEL1K66sgR2w=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-core/@agentos-software/codex-cli": ["@agentos-software/codex-cli@0.3.3", "", {}, "sha512-63f4jymlxe4S003/4Fiu9Y/BAzT6ajHEDidfNqv39SkWNJWxT1ndY+j1/7XYT6NsGgg2ZSo+OGuexlkL8Jx1RA=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-core/@agentos-software/manifest": ["@agentos-software/manifest@0.2.7", "", {}, "sha512-1e4J8YRR8Ftj7ftKFdqAH2m5ksHz9v+XUGMzirDPGHwXaGzjham3SdWadpqHOE7q3GIWJdP4uWZeY22fquJNrg=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-core/@rivet-dev/agentos-runtime-core": ["@rivet-dev/agentos-runtime-core@0.2.7", "", { "dependencies": { "@rivet-dev/agentos-runtime-sidecar": "0.2.7", "@rivetkit/bare-ts": "^0.6.2", "zod": "^4.1.11" } }, "sha512-Dih3ex/FIr69VhReUIAapBBNrghkA26IMlPs9fiWkrj0QEjdDTCMvfBkhseQelUdzmL6hCLnIrru2cQ29KwxCQ=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-sidecar/@rivet-dev/agentos-sidecar-darwin-arm64": ["@rivet-dev/agentos-sidecar-darwin-arm64@0.2.7", "", { "os": "darwin", "cpu": "arm64" }, "sha512-/FgUVxg27IQQ0swBXVBg8s3spaFk8tA+icQVa0KYC7eOZF+2fhNXcjuQrkCB9yoNHd2YMNrWp4PB/mQ16yg3Ag=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-sidecar/@rivet-dev/agentos-sidecar-darwin-x64": ["@rivet-dev/agentos-sidecar-darwin-x64@0.2.7", "", { "os": "darwin", "cpu": "x64" }, "sha512-akj3VqdmcPHPzBDwBYpScjeudjpEsTBJAL5iGnPUEoLA3hLJrBdoXovbR9xMQgixontPDYu4rvttiTQUt0doug=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-sidecar/@rivet-dev/agentos-sidecar-linux-arm64-gnu": ["@rivet-dev/agentos-sidecar-linux-arm64-gnu@0.2.7", "", { "os": "linux", "cpu": "arm64" }, "sha512-Hyrxo6Bh5aF6iqt076xN8VggxfCMN9qGkMb/BBH+LgtQQX2Pq76wJRZCltm8g5TOCxlczob8E5HqMdpCkw0Z9w=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-sidecar/@rivet-dev/agentos-sidecar-linux-x64-gnu": ["@rivet-dev/agentos-sidecar-linux-x64-gnu@0.2.7", "", { "os": "linux", "cpu": "x64" }, "sha512-blcgYjNG1zE3bI6SFOfhTHe8NrSm3QGannfNR6RQCoalif9Hf7bpxR/ha3uMKH+0fmlmuuc8LUi/O2N/uoiB9Q=="], + "@rivetkit/react/@tanstack/react-store/@tanstack/store": ["@tanstack/store@0.7.7", "", {}, "sha512-xa6pTan1bcaqYDS9BDpSiS63qa6EoDkPN9RsRaxHuDdVDNntzq3xNwR5YKTU/V3SkSyC9T4YVOPh2zRQN0nhIQ=="], "@rivetkit/react/rivetkit/@rivetkit/engine-cli": ["@rivetkit/engine-cli@2.3.7", "", { "optionalDependencies": { "@rivetkit/engine-cli-darwin-arm64": "2.3.7", "@rivetkit/engine-cli-darwin-x64": "2.3.7", "@rivetkit/engine-cli-linux-arm64-musl": "2.3.7", "@rivetkit/engine-cli-linux-x64-musl": "2.3.7", "@rivetkit/engine-cli-win32-x64": "2.3.7" } }, "sha512-CezLwJ0B7dWDbA7qM6Aq04mwnrJAdrDActRrrcb4NBa20h7wO9KPAYBwyJz/dRnKm9EUUNcFZ6hrSDpp6T3+Rg=="], @@ -4578,8 +4684,11 @@ "npm-package-arg/hosted-git-info/lru-cache": ["lru-cache@10.4.3", "", {}, "sha512-JNAzZcXrCt42VGLuYz0zfAzDfAvJWW6AfYlDBQyDV5DClI2m5sAmK+OIO7s59XfsRsWHp02jAJrRadPRGTt6SQ=="], +<<<<<<< Updated upstream "ora/strip-ansi/ansi-regex": ["ansi-regex@6.2.2", "", {}, "sha512-Bq3SmSpyFHaWjPk8If9yc6svM8c56dB5BAtW4Qbw5jHTwwXXcTLoRMkpDJp6VL0XzlWaCHTXrkFURMYmD0sLqg=="], +======= +>>>>>>> Stashed changes "pkg-up/find-up/locate-path": ["locate-path@3.0.0", "", { "dependencies": { "p-locate": "^3.0.0", "path-exists": "^3.0.0" } }, "sha512-7AO748wWnIhNqAuaty2ZWHkQHRSNfPVIsPIfwEOWO22AmaoVrWavlOcMR5nzTLNYvp36X220/maaRsrec1G65A=="], "protobufjs/@types/node/undici-types": ["undici-types@8.3.0", "", {}, "sha512-j375ScV60dom+YkPFIfTLcOiPxkN/buHz5GobjLhixFuANaNs3C9l4GmrWqejgXWJ7BbJcFYpTEUkS1Ge8bpZQ=="], @@ -4793,6 +4902,11 @@ "@expo/package-manager/ora/strip-ansi/ansi-regex": ["ansi-regex@4.1.1", "", {}, "sha512-ILlv4k/3f6vfQ4OoP2AGvirOktlQ98ZEL1k9FaQjxa3L1abBgbuTDAdPOpvbGncC0BTVQrl+OM8xZGK6tWXt7g=="], "@google/genai/google-auth-library/gaxios/node-fetch": ["node-fetch@3.3.2", "", { "dependencies": { "data-uri-to-buffer": "^4.0.0", "fetch-blob": "^3.1.4", "formdata-polyfill": "^4.0.10" } }, "sha512-dRB78srN/l6gqWulah9SrxeYnxeddIG30+GOqK/9OlLVyLg3HPnr6SqOWTWOXKRwC2eGYCkZ59NNuSgvSrpgOA=="], +<<<<<<< Updated upstream +======= + + "@react-native/codegen/yargs/cliui/strip-ansi": ["strip-ansi@6.0.1", "", { "dependencies": { "ansi-regex": "^5.0.1" } }, "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A=="], +>>>>>>> Stashed changes "@rivet-dev/agentos/rivetkit/@rivetkit/engine-cli/@rivetkit/engine-cli-darwin-arm64": ["@rivetkit/engine-cli-darwin-arm64@2.3.7", "", { "os": "darwin", "cpu": "arm64" }, "sha512-F3yGSDIaW94BZzuAm3erQRT/Ki55wHJ/b6tOaE7d9tRmTAZw/XqHmjNdUYjOvFUQKLb+SSsOittM4dINrAANQQ=="], @@ -4854,12 +4968,15 @@ "@rivetkit/react/rivetkit/@rivetkit/rivetkit-napi/@rivetkit/rivetkit-napi-linux-x64-musl": ["@rivetkit/rivetkit-napi-linux-x64-musl@2.3.7", "", { "os": "linux", "cpu": "x64" }, "sha512-8RGzXD33GH1/DWufFzCZRI+npF5IL/9z7Ja3pthsuYgrL+axGG0iqfAjbwj5HHnB/ceUGQVT+uCKzoLnG+odtw=="], + "@rivet-dev/agentos/@rivet-dev/agentos-core/@rivet-dev/agentos-runtime-core/@rivet-dev/agentos-runtime-sidecar": ["@rivet-dev/agentos-runtime-sidecar@0.2.7", "", { "optionalDependencies": { "@rivet-dev/agentos-runtime-sidecar-darwin-arm64": "0.2.7", "@rivet-dev/agentos-runtime-sidecar-darwin-x64": "0.2.7", "@rivet-dev/agentos-runtime-sidecar-linux-arm64-gnu": "0.2.7", "@rivet-dev/agentos-runtime-sidecar-linux-x64-gnu": "0.2.7" } }, "sha512-QuAEG3/IKiBDlUbVYBNKc4h0TcT6DDYKlz58lwniv/L0v4qpJBwKLYikdSyNjp1H8eVZXFr7UsaaqFmuvCSsug=="], + "cli-highlight/yargs/cliui/strip-ansi": ["strip-ansi@6.0.1", "", { "dependencies": { "ansi-regex": "^5.0.1" } }, "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A=="], "cli-highlight/yargs/string-width/emoji-regex": ["emoji-regex@8.0.0", "", {}, "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A=="], "cli-highlight/yargs/string-width/strip-ansi": ["strip-ansi@6.0.1", "", { "dependencies": { "ansi-regex": "^5.0.1" } }, "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A=="], +<<<<<<< Updated upstream "concurrently/yargs/cliui/strip-ansi": ["strip-ansi@7.2.0", "", { "dependencies": { "ansi-regex": "^6.2.2" } }, "sha512-yDPMNjp4WyfYBkHnjIRLfca1i6KMyGCtsVgoKe/z1+6vukgaENdgGBZt+ZmKPc4gavvEZ5OgHfHdrazhgNyG7w=="], "concurrently/yargs/cliui/wrap-ansi": ["wrap-ansi@9.0.2", "", { "dependencies": { "ansi-styles": "^6.2.1", "string-width": "^7.0.0", "strip-ansi": "^7.1.0" } }, "sha512-42AtmgqjV+X1VpdOfyTGOYRi0/zsoLqtXQckTmqTeybT+BDIbM/Guxo7x3pE2vtpr1ok6xRqM9OpBe+Jyoqyww=="], @@ -4867,6 +4984,13 @@ "md5.js/hash-base/readable-stream/safe-buffer": ["safe-buffer@5.1.2", "", {}, "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g=="], "md5.js/hash-base/readable-stream/string_decoder": ["string_decoder@1.1.1", "", { "dependencies": { "safe-buffer": "~5.1.0" } }, "sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg=="], +======= + "metro/yargs/cliui/strip-ansi": ["strip-ansi@6.0.1", "", { "dependencies": { "ansi-regex": "^5.0.1" } }, "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A=="], + + "metro/yargs/string-width/emoji-regex": ["emoji-regex@8.0.0", "", {}, "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A=="], + + "metro/yargs/string-width/strip-ansi": ["strip-ansi@6.0.1", "", { "dependencies": { "ansi-regex": "^5.0.1" } }, "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A=="], +>>>>>>> Stashed changes "pkg-up/find-up/locate-path/p-locate": ["p-locate@3.0.0", "", { "dependencies": { "p-limit": "^2.0.0" } }, "sha512-x+12w/To+4GFfgJhBEpiDcLozRJGegY+Ei7/z0tSLkMmxGZNybVMSfWj9aJn8Z5Fc7dBUNJOOVgPv2H7IwulSQ=="], @@ -4928,9 +5052,19 @@ "@google/genai/google-auth-library/gaxios/node-fetch/data-uri-to-buffer": ["data-uri-to-buffer@4.0.1", "", {}, "sha512-0R9ikRb668HB7QDxT1vkpuUBtqc53YyAwMwGeUFKRojY/NWKvdZ+9UYtRfGmhqNbRkTSVpMbmyhXipFFv2cb/A=="], +<<<<<<< Updated upstream "concurrently/yargs/cliui/strip-ansi/ansi-regex": ["ansi-regex@6.2.2", "", {}, "sha512-Bq3SmSpyFHaWjPk8If9yc6svM8c56dB5BAtW4Qbw5jHTwwXXcTLoRMkpDJp6VL0XzlWaCHTXrkFURMYmD0sLqg=="], "concurrently/yargs/cliui/wrap-ansi/ansi-styles": ["ansi-styles@6.2.3", "", {}, "sha512-4Dj6M28JB+oAH8kFkTLUo+a2jwOFkuqb3yucU0CANcRRUbxS0cP0nZYCGjcc3BNXwRIsUVmDGgzawme7zvJHvg=="], +======= + "@rivet-dev/agentos/@rivet-dev/agentos-core/@rivet-dev/agentos-runtime-core/@rivet-dev/agentos-runtime-sidecar/@rivet-dev/agentos-runtime-sidecar-darwin-arm64": ["@rivet-dev/agentos-runtime-sidecar-darwin-arm64@0.2.7", "", { "os": "darwin", "cpu": "arm64" }, "sha512-u14Mr7wp4h7IF8mc7jXREBh1xPOoLCzwMVUH/zpa/Y7eiGb6LE7RPW2n+nC0VpciiLf/7gYejU6QboJnhiq1uw=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-core/@rivet-dev/agentos-runtime-core/@rivet-dev/agentos-runtime-sidecar/@rivet-dev/agentos-runtime-sidecar-darwin-x64": ["@rivet-dev/agentos-runtime-sidecar-darwin-x64@0.2.7", "", { "os": "darwin", "cpu": "x64" }, "sha512-4IABmx8Pi7f76J8aMypln5dZs0qsWVXXW31oA7v4I3e11EGvCmsubjCEO+9YLvEuk6La3JcSO+685bs45twIvA=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-core/@rivet-dev/agentos-runtime-core/@rivet-dev/agentos-runtime-sidecar/@rivet-dev/agentos-runtime-sidecar-linux-arm64-gnu": ["@rivet-dev/agentos-runtime-sidecar-linux-arm64-gnu@0.2.7", "", { "os": "linux", "cpu": "arm64" }, "sha512-YHZFlGAljRMjceUsVU7e1GjTeM4QNj6/OjGcpprciyKosRNny8aoVsA4gJbe0dCNEbwVmO6peczFVAt5k54VEw=="], + + "@rivet-dev/agentos/@rivet-dev/agentos-core/@rivet-dev/agentos-runtime-core/@rivet-dev/agentos-runtime-sidecar/@rivet-dev/agentos-runtime-sidecar-linux-x64-gnu": ["@rivet-dev/agentos-runtime-sidecar-linux-x64-gnu@0.2.7", "", { "os": "linux", "cpu": "x64" }, "sha512-wcHg/ifVWKqFosNN7YLNsP/SrZxZccd2UP2EPQHnIcRyMg+w14LpgdDcIsPWO/HvS7+78OwRsCck5IIOeonIUw=="], +>>>>>>> Stashed changes "pkg-up/find-up/locate-path/p-locate/p-limit": ["p-limit@2.3.0", "", { "dependencies": { "p-try": "^2.0.0" } }, "sha512-//88mFWSJx8lxCzwdAABTJL2MyWB12+eIY7MDL2SqLmAkeKU9qxRvWuSyTjm3FUmpBEMuFfckAIqEaVGUDxb6w=="], diff --git a/packages/agents/package.json b/packages/agents/package.json index 6c7185e..4b00ebb 100644 --- a/packages/agents/package.json +++ b/packages/agents/package.json @@ -15,7 +15,11 @@ "@code/backend": "workspace:*", "@code/env": "workspace:*", "@flue/runtime": "latest", +<<<<<<< Updated upstream "@rivet-dev/agentos-core": "catalog:", +======= + "@rivet-dev/agentos-core": "^0.2.10", +>>>>>>> Stashed changes "convex": "catalog:", "hono": "4.12.30", "valibot": "^1.4.2" diff --git a/packages/agents/src/agents/zopu.ts b/packages/agents/src/agents/zopu.ts index dbbbd29..7c4a4b4 100644 --- a/packages/agents/src/agents/zopu.ts +++ b/packages/agents/src/agents/zopu.ts @@ -2,6 +2,10 @@ import path from "node:path"; import { parseAgentEnv } from "@code/env/agent"; import { defineAgent } from "@flue/runtime"; +<<<<<<< Updated upstream +======= +import type { AgentRouteHandler } from "@flue/runtime"; +>>>>>>> Stashed changes // import { agentos } from "../sandboxes/agentos"; import { local } from "@flue/runtime/node"; @@ -10,7 +14,11 @@ import { paseoCli } from "../tools/paseo"; const repositoryRoot = path.resolve(process.cwd(), "../.."); +<<<<<<< Updated upstream export { authenticatedAgentRoute as route } from "../auth"; +======= +export const route: AgentRouteHandler = (_context, next) => next(); +>>>>>>> Stashed changes export default defineAgent(({ env }) => { const { AGENT_MODEL_NAME, AGENT_MODEL_PROVIDER } = parseAgentEnv(env); diff --git a/packages/primitives/src/project.ts b/packages/primitives/src/project.ts index d6525f7..fe31b9e 100644 --- a/packages/primitives/src/project.ts +++ b/packages/primitives/src/project.ts @@ -284,6 +284,7 @@ export const preparePublicGitSource = ( } const segments = repositoryPath.split("/").filter((s) => s.length > 0); + // eslint-disable-next-line unicorn/prefer-at -- backend Convex tsconfig targets pre-ES2022 const lastSegment = segments[segments.length - 1]; if (!lastSegment || isWhitespaceOnly(lastSegment)) { return yield* Effect.fail(INVALID_GIT_URL);