feat: Slice 1 polish - MiMo V2.5 model, visible reasoning, image attachments, mobile keyboard fix
- Switch conversation agent to xiaomi/mimo-v2.5 (multimodal: text + image) - Render native reasoning parts as live 'Thinking trace' (streaming open, collapsed after completion); inline <think> extraction for streaming models - Image attachments: picker (up to 4, 10MB each), base64 to Flue AgentPromptImage, authenticated blob-URL replay for historical images - Mobile keyboard viewport fix: visual-viewport hook, fixed shell, interactive-widget=resizes-content, header pinned, composer follows keyboard - Conversation to Signal to proposed Work: Convex persistence, Effect validation in @code/work-os, Work cards with exact source provenance - Streamdown markdown + Mermaid chart rendering in chat messages - Flue tool turns hidden, reasoning-containing turns remain visible - Frontend regression tests: keyboard viewport, responsive shell, attachment overflow, authenticated images, reasoning traces, transforms - .env.example updated to xiaomi/mimo-v2.5 config
This commit is contained in:
-Puter
470
docs/PRODUCT.md
470
docs/PRODUCT.md
@@ -1,228 +1,422 @@
|
||||
# Zopu Work OS — Product
|
||||
# Zopu Work OS — Product Specification
|
||||
|
||||
> Working spec · product/design/ops/research/agent teams · concepts, behavior, boundaries, value. Excludes implementation, infra, tech choices, low-level UI.
|
||||
> **Related:** `dev-loop.md` defines delivery; `slices.md` defines product increments; `evaluation.md` defines quality measurement.
|
||||
|
||||
## 1. Summary
|
||||
> **Status:** Working source of truth
|
||||
> **Audience:** product, design, engineering, agents
|
||||
> **Normative words:** **MUST** = required, **SHOULD** = default, **MAY** = optional
|
||||
> **Product boundary:** this file defines *what and why*, not implementation details.
|
||||
|
||||
Zopu Work OS is a persistent OS for technical founders, product engineers, and small teams managing the full lifecycle of building and growing software across products, companies, repos, customers, and functions. It replaces fragmented chats, trackers, docs, and manually coordinated AI agents with one coherent system organized around **units of work**.
|
||||
## 1. Thesis
|
||||
|
||||
One continuous workspace discovers work, builds understanding, coordinates execution, requests human judgment when needed, tracks outcomes, and retains knowledge. Not a better chat app or just another PM tool — it continuously converts company signals into structured, persistent, executable work.
|
||||
Zopu is a **completion system for durable units of work**, not a chat wrapper and not a coding-agent launcher.
|
||||
|
||||
**Promise:** One workspace that understands the company, turns signals into work, progresses work autonomously, and brings the human in only when direction, judgment, permission, or taste is required.
|
||||
The product converts conversation and external events into verified outcomes:
|
||||
|
||||
## 2. Customer
|
||||
```text
|
||||
Talk/events → Signals → Work → Definition → Design → Slices
|
||||
→ Resolution → Verification → Delivery → Observation → Learning
|
||||
```
|
||||
|
||||
**Ideal:** technical founder/small team that operates 1+ software products across several companies/clients/repos; moves between engineering, product, support, sales, marketing, ops, strategy; uses many tools without a unified model; uses AI coding tools but finds session/thread fragmentation; needs more execution capacity without hiring per function; needs context continuity, reliable delegation, visibility into autonomous work.
|
||||
The core promise:
|
||||
|
||||
**Secondary:** product engineers (several initiatives), fractional CTOs, agencies/studios, solo founders, small product/eng teams, multi-internal-product operators.
|
||||
> Given an accepted unit of work, Zopu keeps advancing it until a verified outcome exists or a precise terminal blocker is recorded.
|
||||
|
||||
Technical-first because code is a clear execution domain (measurable artifacts, established workflows, strong familiarity). Broader direction: research, content, marketing, support, product ops, sales enablement, other knowledge/creative work.
|
||||
Agents may propose, plan, implement, review, and test. **The system decides completion from evidence.**
|
||||
|
||||
## 3. Problem — work is fragmented three ways
|
||||
## 2. Initial customer and scope
|
||||
|
||||
| Fragmentation | Detail |
|
||||
| --- | --- |
|
||||
| **Across tools** | One problem spans support→analytics→tracker→browser→repo→PR→release notes→customer comms. Each tool stores a partial view; none owns the lifecycle. |
|
||||
| **Across AI sessions** | Chat/thread-organized work forces repeated decisions: which conversation, what context to restate, which model/agent, where to store output, how it relates to existing work, what changed after shipping. Conversation becomes structure though conversations are temporary and work is persistent. |
|
||||
| **Founders as coordination** | Small-team founders bridge every system/function: remember decisions, connect feedback to work, check blockers, move work between tools, review AI output, decide next steps. The founder becomes the human integration bus. |
|
||||
### ICP v0
|
||||
|
||||
Zopu removes this burden by maintaining a persistent model of work, context, state, evidence, execution, and outcomes.
|
||||
Technical founders and small engineering teams working in one Git repository.
|
||||
|
||||
## 4. Thesis
|
||||
### Supported v0 workflow
|
||||
|
||||
- **Conversation is the interface, not the structure.** The durable structure is the **work unit**. Changing tasks must not require a new chat; the persistent conversation's scope moves between whole workspace and a specific work unit.
|
||||
- **Work = outcomes, not activity.** Represent: _fix Safari OAuth failures; reduce onboarding abandonment; launch team invitations; resolve a billing escalation; rewrite the pricing page; validate a direction._ Do not promote every message/tool-call/agent action to a top-level task.
|
||||
- **The product participates in work** — not just store/display: discover, understand, plan, execute, verify, publish, measure.
|
||||
- **Autonomy reduces attention, not adds noise.** Successful when it makes correct progress, informs at the right level, asks only when necessary.
|
||||
- **Knowledge compounds.** Every decision, result, failure, signal, artifact improves understanding and accelerates/future-proofs future work.
|
||||
```text
|
||||
Project chat
|
||||
→ actionable Signal
|
||||
→ approved Work Definition
|
||||
→ lightweight Design Packet
|
||||
→ vertical slices
|
||||
→ isolated coding run
|
||||
→ independent verification
|
||||
→ branch + pull request
|
||||
→ human merge
|
||||
→ result assessment
|
||||
```
|
||||
|
||||
## 5. Core objects
|
||||
### v0 constraints
|
||||
|
||||
Use a small set of durable concepts that stays stable across domains.
|
||||
- One user/organization/project/repository path first.
|
||||
- Web interface only.
|
||||
- One implementation harness first.
|
||||
- One sandbox provider first.
|
||||
- Manual merge.
|
||||
- No autonomous production mutation.
|
||||
- No arbitrary generated tools receiving immediate execution authority.
|
||||
- No generic support for every founder workflow yet.
|
||||
|
||||
### Organization
|
||||
The domain must remain broader than Git, but the implementation should prove quality on software delivery first.
|
||||
|
||||
Hard business/permission/knowledge boundary. Represents a company, client, startup, internal BU, or personal portfolio. Owns its users, products, policies, integrations, knowledge, work, history. **Information never moves between organizations implicitly.**
|
||||
## 3. Product surfaces
|
||||
|
||||
### Project / product
|
||||
The primary interface remains intentionally small:
|
||||
|
||||
Durable operating context within an org: software product, repo-backed app, client engagement, internal platform, website/service, focused initiative. Contains goals, product knowledge, conventions, connected sources, relevant people, active work. Reduces context ambiguity without forcing manual folder structures.
|
||||
```text
|
||||
1. Continuous project conversation
|
||||
2. Work cards
|
||||
3. Human attention queue
|
||||
```
|
||||
|
||||
### Goal
|
||||
### Continuous conversation
|
||||
|
||||
What the org/project is trying to achieve (e.g. reduce onboarding failure, reach a reliability target, launch enterprise support, improve trial→paid, close first ten enterprise customers). Distinguishes valuable work from merely possible. A work unit may support 1+ goals but every important unit has a clear reason.
|
||||
One project-level conversation is used to:
|
||||
|
||||
- discuss intent;
|
||||
- create Signals;
|
||||
- ask about Work;
|
||||
- add evidence or constraints;
|
||||
- change priorities;
|
||||
- respond to agent questions.
|
||||
|
||||
Conversation is not the system of record for execution state.
|
||||
|
||||
### Work cards
|
||||
|
||||
A Work card is the durable, inspectable representation of one desired outcome. It exposes definition, design, execution, evidence, delivery, and result without forcing the user to inspect raw agent transcripts.
|
||||
|
||||
### Attention queue
|
||||
|
||||
All decisions requiring a human are first-class objects:
|
||||
|
||||
- clarify intent;
|
||||
- approve definition/design;
|
||||
- grant permission;
|
||||
- select an alternative;
|
||||
- review a slice;
|
||||
- approve merge/release;
|
||||
- accept risk.
|
||||
|
||||
## 4. Canonical domain
|
||||
|
||||
### Signal
|
||||
|
||||
Raw info that may matter: support ticket, customer comment, error spike, deploy failure, sales objection, team-channel message, analytics change, founder thought. **Not automatically a task.** Fates: attach to existing work, convert to candidate, save as knowledge, dismiss, mark irrelevant/duplicate.
|
||||
Evidence that may require attention.
|
||||
|
||||
```text
|
||||
Signal
|
||||
├── exact source/provenance
|
||||
├── extracted meaning
|
||||
├── project context
|
||||
├── confidence
|
||||
├── related signals
|
||||
└── candidate Work links
|
||||
```
|
||||
|
||||
A Signal MUST preserve the original source. A model summary never replaces evidence.
|
||||
|
||||
### Work
|
||||
|
||||
A durable desired outcome, not a message, issue, session, branch, or PR.
|
||||
|
||||
```text
|
||||
Work
|
||||
├── objective
|
||||
├── reason/user impact
|
||||
├── source Signals
|
||||
├── Work Definition
|
||||
├── Design Packet
|
||||
├── slices/steps
|
||||
├── runs/attempts
|
||||
├── questions/decisions
|
||||
├── artifacts/evidence
|
||||
├── delivery
|
||||
└── result
|
||||
```
|
||||
|
||||
### Candidate work
|
||||
### Work Definition
|
||||
|
||||
Proposed work unit not yet accepted as durable active work. Created when a signal/cluster seems actionable. Explains: proposed outcome, why it matters, supporting evidence, project/goal, system confidence, whether similar work exists. User can accept/edit/merge/defer/dismiss.
|
||||
A testable contract before implementation:
|
||||
|
||||
### Work unit
|
||||
- problem;
|
||||
- desired outcome;
|
||||
- affected users;
|
||||
- in/out of scope;
|
||||
- acceptance criteria;
|
||||
- constraints;
|
||||
- assumptions;
|
||||
- unresolved questions;
|
||||
- risk class;
|
||||
- required artifacts;
|
||||
- rollout/rollback requirements when applicable.
|
||||
|
||||
Central object. Persistent, stateful representation of one meaningful outcome. Owns: objective, desired result, scope/non-goals, current understanding, requirements, success criteria, status, priority, dependencies, blockers, decisions, evidence, plan, human actions, agent activity, artifacts, results, learning.
|
||||
### Design Packet
|
||||
|
||||
Persists across conversations, agent runs, people, tools, time. Not identical to (though may contain): a single prompt, chat thread, agent session, PR, checklist item, branch.
|
||||
A reviewable implementation intent:
|
||||
|
||||
### Step
|
||||
- impact map;
|
||||
- architecture summary/sequence;
|
||||
- file-tree diff;
|
||||
- call-flow diff;
|
||||
- key types/interfaces;
|
||||
- invariants;
|
||||
- migration/security/operational concerns;
|
||||
- vertical slice plan;
|
||||
- explicit trade-offs and deviations.
|
||||
|
||||
Bounded action within a work unit: inspect logs, reproduce failure, draft plan, add tests, review preview, contact customers. Organizes execution but must not become another noisy task layer — visible when useful, hidden when only the outcome matters.
|
||||
### Vertical Slice
|
||||
|
||||
### Run
|
||||
A bounded unit of implementation that produces observable, independently verifiable progress.
|
||||
|
||||
One agent/workflow attempt to progress a work unit: research root cause, implement, review, verify, prep release. A unit can have parallel/repeated runs. Subordinate to the work unit — never replaces it as the primary object.
|
||||
A valid slice answers:
|
||||
|
||||
- what behavior becomes observable;
|
||||
- what code boundaries change;
|
||||
- what artifacts must exist;
|
||||
- what evidence proves completion;
|
||||
- what review is required before continuation.
|
||||
|
||||
### Artifact
|
||||
### Kit
|
||||
|
||||
Durable output/evidence: PR, commit, patch, design, spec, test report, screenshot, preview, research memo, customer-response draft, launch plan. Attached to the work unit, accessible from history and current state.
|
||||
A versioned executable configuration for resolving a class of Work:
|
||||
|
||||
### Decision
|
||||
- roles/agent definitions;
|
||||
- tools and grants;
|
||||
- skills/instructions;
|
||||
- context policy;
|
||||
- runtime requirements;
|
||||
- harness policy;
|
||||
- budgets;
|
||||
- output contracts;
|
||||
- verification recipes;
|
||||
- escalation policy.
|
||||
|
||||
Records an important human/system choice + reasoning: approve plan, choose design direction, reject a migration, delay a feature, accept a limitation. Stays visible after the conversation so future agents don't repeat settled debates.
|
||||
A Kit is not an agent and not a run. v0 uses one static Coding Kit; dynamic Kit Builder comes after the loop is reliable.
|
||||
|
||||
### Approval
|
||||
### Run and Attempt
|
||||
|
||||
Specific human permission before a sensitive/consequential action: merge code, deploy prod, send customer message, access sensitive data, spend money, change business policy. Precise, inspectable, bounded — user knows exactly what happens after approval.
|
||||
A Run coordinates execution for Work or a slice. An Attempt is one bounded execution by one harness in one environment.
|
||||
|
||||
### Result & learning
|
||||
Attempt terminal classifications:
|
||||
|
||||
Result records post-completion reality, comparing: intended outcome, expected impact, actual outcome, measurement period, unexpected effects, recommended follow-up. Learning = reusable knowledge extracted to improve future planning/execution across the relevant org/project.
|
||||
```text
|
||||
Succeeded | RetryableFailure | NeedsInput | Blocked
|
||||
| VerificationFailed | BudgetExhausted | Cancelled | PermanentFailure
|
||||
```
|
||||
|
||||
## 6. Work lifecycle
|
||||
“Agent working” is not a durable outcome.
|
||||
|
||||
Four conceptually consistent phases across all domains.
|
||||
### Artifact and Evidence
|
||||
|
||||
| Phase | The system… | Goal/output |
|
||||
| --- | --- | --- |
|
||||
| **Discover** | Extracts, groups, dedupes, connects signals; proposes candidate work; relates to goals/projects. | Identify meaningful work with sufficient evidence/relevance — _not_ the largest backlog. |
|
||||
| **Understand** | Gathers context — research, code/system inspection, customer evidence, analytics, prior decisions, constraints, open questions, risks, success criteria. | Actionable understanding, not an endless report. |
|
||||
| **Create & iterate** | Coordinates production — code, specs, designs, docs, tests, customer comms, launch assets, research, business recommendations. Produces intermediate artifacts, verifies, incorporates feedback without losing continuity. | Working solution. |
|
||||
| **Publish & learn** | Releases/delivers/shares, then follows the outcome — deploy status, error rates, adoption, customer reactions, conversion, support volume, revenue impact, qualitative feedback. | Measured result. |
|
||||
Examples:
|
||||
|
||||
Lifecycle ends only when work produces a result, is intentionally stopped, or is superseded.
|
||||
- plan/design;
|
||||
- diff;
|
||||
- test report;
|
||||
- screenshot/video;
|
||||
- commit;
|
||||
- PR;
|
||||
- preview;
|
||||
- deployment;
|
||||
- runtime logs;
|
||||
- performance/security reports.
|
||||
|
||||
## 7. Work-unit boundaries
|
||||
Every artifact SHOULD include producer, Work/slice/run, source revision, environment, provenance, and verification status.
|
||||
|
||||
Quality depends on how work is divided.
|
||||
### Result
|
||||
|
||||
**Good unit** = one independently meaningful outcome, summarizable in one clear sentence, reaches a recognizable result. Good: _fix Safari OAuth callback failures; decide SAML support this quarter; reduce onboarding time-to-first-value; prepare & launch team invitations._ Poor: _improve the product; marketing; work on onboarding; open the repo; read the logs_ (too broad or too granular).
|
||||
Delivery is not necessarily outcome. Result compares intended and actual impact:
|
||||
|
||||
**Split when:** multiple independent outcomes; different owners/approval paths; different orgs/permission boundaries; different deadlines/success criteria; one part finishes while another stays active; hard to summarize/review; a child deserves its own lifecycle/result.
|
||||
```text
|
||||
Achieved | PartiallyAchieved | NotAchieved | Regressed | Inconclusive
|
||||
```
|
||||
|
||||
**Merge when:** two candidates describe the same outcome; different channels reported the same problem; one candidate is just evidence for an existing unit; neither can be completed independently. System may propose merges; uncertain merges stay reversible/user-reviewable.
|
||||
### Learning
|
||||
|
||||
**Parent/child:** large initiatives contain child units; parent = larger result, each child still independently meaningful. _Parent: Restore OAuth reliability → children: fix Safari callbacks, improve setup diagnostics, update docs, notify customers, monitor post-release completion._ Parent summarizes progress/dependencies without replacing child detail.
|
||||
Post-work observations that may propose updates to:
|
||||
|
||||
## 8. Conversation model
|
||||
- project knowledge;
|
||||
- architecture decisions;
|
||||
- test recipes;
|
||||
- skills;
|
||||
- tools;
|
||||
- Kit definitions;
|
||||
- planning heuristics.
|
||||
|
||||
One persistent conversational surface, two scopes.
|
||||
Canonical knowledge updates require review.
|
||||
|
||||
| Scope | Use |
|
||||
| --- | --- |
|
||||
| **Global** | Think/act across workspace: introduce ideas/problems, ask what needs attention, compare work across projects, reprioritize, create/modify work, request summaries, discuss dependencies, request research/execution. System auto-connects messages to relevant projects/units while preserving source. |
|
||||
| **Contextual** | Same composer focused on one work unit: add requirements, answer questions, review progress, change direction, approve a plan, request another attempt, ask for explanation, continue from an artifact. Entering does **not** create a new thread — it changes the active scope. |
|
||||
## 5. Quality doctrine
|
||||
|
||||
Conversation is not the source of truth. Important facts/decisions/requirements/approvals/artifacts/results are extracted into structured objects while preserving links to source conversation.
|
||||
High-quality software is evaluated across:
|
||||
|
||||
## 9. Autonomous behavior
|
||||
| Dimension | Required question |
|
||||
|---|---|
|
||||
| Correctness | Does behavior satisfy the accepted criteria? |
|
||||
| Regression safety | Did existing behavior remain valid? |
|
||||
| Maintainability | Does the change preserve understandable boundaries? |
|
||||
| Security | Are permissions, secrets, data, and dependencies safe? |
|
||||
| Reliability | Are failures and edge cases handled? |
|
||||
| Operability | Can it be deployed, observed, debugged, and rolled back? |
|
||||
| Performance | Are expected resource limits preserved? |
|
||||
| UX | Does the actual user path work? |
|
||||
| Traceability | Can claims be tied to evidence and revisions? |
|
||||
| Reversibility | Can risk be disabled or rolled back? |
|
||||
|
||||
The system continuously observes, understands, organizes, executes, escalates, learns.
|
||||
### Completion rule
|
||||
|
||||
**May autonomously:** attach new evidence; update summaries/understanding; detect stale/blocked work; propose new work; run safe research; prepare plans/drafts; produce code/artifacts inside approved boundaries; run verification; suggest priorities; monitor completed work; create follow-up candidates; summarize activity.
|
||||
Work is complete only when:
|
||||
|
||||
**Request human for:** strategic direction; ambiguous product decisions; business tradeoffs; sensitive permissions; high-risk actions; external communication; production changes; priority conflicts; conflicting evidence; actions outside granted policy.
|
||||
1. accepted behavior is implemented on a known revision;
|
||||
2. required checks pass in a known environment;
|
||||
3. design deviations are visible;
|
||||
4. required human gates are satisfied;
|
||||
5. delivery artifacts exist;
|
||||
6. post-release observation is completed when required.
|
||||
|
||||
**Must not:** create speculative work without evidence; treat confidence as certainty; hide failures/uncertainty; silently cross org boundaries; reopen settled decisions without new evidence; perform irreversible actions without authority; optimize for activity over outcomes.
|
||||
A passing test suite is necessary but not sufficient for medium/high-risk work.
|
||||
|
||||
## 10. Human-in-the-loop
|
||||
### Builder-verifier separation
|
||||
|
||||
User must not inspect every unit to find what needs attention. Human requests centralize into an **Attention Queue**. Each request states: what's required, why, the recommendation, supporting evidence, what happens after approval, what happens if the user does nothing, urgency, reversibility. **Categories:** decision · approval · clarification · access request · review · blocker resolution · risk alert.
|
||||
The implementation worker MUST NOT be the sole authority on completion.
|
||||
|
||||
Minimize unnecessary approvals via explicit standing policies while preserving clear control over sensitive actions.
|
||||
```text
|
||||
Builder → candidate output
|
||||
Verifier → independent evidence
|
||||
Resolver → completion decision
|
||||
Human → policy-defined approvals
|
||||
```
|
||||
|
||||
## 11. Provenance & trust
|
||||
### Risk lanes
|
||||
|
||||
User must understand why the system believes something and what caused an action. **Every important claim carries provenance.** Sources: message, ticket, repo change, error report, analytics event, document, agent observation, human decision. Claim status distinguished as: verified · reported · inferred · assumed · conflicting · outdated. Primary interface stays readable; deeper evidence/derivation available on demand. **Never present an agent summary as equivalent to primary evidence.**
|
||||
#### Fast
|
||||
|
||||
## 12. Knowledge model
|
||||
Copy, docs, isolated styling, deterministic mechanical changes.
|
||||
|
||||
Accumulates several kinds; each retains its scope (personal prefs, project facts, org-wide truths never mixed blindly).
|
||||
```text
|
||||
short contract → implement → verify → PR
|
||||
```
|
||||
|
||||
| Kind | Content |
|
||||
| --- | --- |
|
||||
| **Canonical** | Reviewed descriptions: business, product, customers, design principles, architecture concepts, conventions, policies, goals. |
|
||||
| **Operational** | Current structured state: active work, priorities, dependencies, ownership, blockers, approvals, results. |
|
||||
| **Episodic** | History: conversations, runs, errors, decisions, reviews, releases, customer reactions. |
|
||||
| **Learned patterns** | Reusable conclusions: common failure causes, customer prefs, repeated objections, effective launch patterns, known limitations, preferred technical/product approaches. |
|
||||
#### Standard
|
||||
|
||||
## 13. Product boundaries
|
||||
Normal features, APIs, workflows, changes spanning a few modules.
|
||||
|
||||
| Boundary | Rule |
|
||||
| --- | --- |
|
||||
| **Control layer, not tool replacement** | Specialist systems (source control, support, comms, analytics, billing, deployment, docs) keep native records/actions. Zopu provides the unified model: what matters, its state, next step, whether outcome worked. |
|
||||
| **Own the work graph** | Connects organizations→projects→goals→signals→work units→dependencies→decisions→runs→artifacts→results→learnings. Durable source of coordination/context. |
|
||||
| **Execution is replaceable** | Execution is a capability beneath the work unit. Users shouldn't care which agent/model/harness ran unless inspection is useful. |
|
||||
| **No unnecessary AI config** | Users shouldn't normally choose model, thinking level, agent framework, context-window strategy, execution runtime, tool routing. System chooses by task/risk/cost/policy. |
|
||||
```text
|
||||
definition → combined design → 1–3 slices → verify → review → PR
|
||||
```
|
||||
|
||||
## 14. Optimization
|
||||
#### Critical
|
||||
|
||||
**Optimize for: maximum useful progress with minimum required human attention.**
|
||||
Auth, billing, permissions, migrations, shared infrastructure, destructive operations.
|
||||
|
||||
Measures: correct extraction of meaningful work; low false-positive candidates; signal→understanding time; time to first useful action; accepted units reaching meaningful outcomes; reduced repeated context gathering; human attention per outcome; decision/output quality; trust/inspectability/reversibility; knowledge reuse; improvement from past results.
|
||||
```text
|
||||
definition approval → architecture approval → program-design approval
|
||||
→ one slice at a time → staged release → observation/rollback gate
|
||||
```
|
||||
|
||||
**Don't primarily optimize:** chat count, time in interface, task count, agent-run count, notification count, raw model usage.
|
||||
## 6. Resolver contract
|
||||
|
||||
A successful day: user opens briefly, resolves a few high-value decisions, sees many units progressed correctly without them.
|
||||
The Work Resolver is the central product engine.
|
||||
|
||||
## 15. Business value
|
||||
It MUST continuously answer:
|
||||
|
||||
| Form | Value |
|
||||
| --- | --- |
|
||||
| **Execution capacity** | Small team progresses more work without proportional headcount. |
|
||||
| **Coordination reduction** | Handles repetitive context-gathering, state updates, linking, follow-ups, output prep. |
|
||||
| **Continuity** | Work keeps context, history, decisions, artifacts across tools/time. |
|
||||
| **Better opportunity capture** | Notices recurring problems, customer opportunities, operational risks, key relationships teams otherwise miss. |
|
||||
- What remains incomplete?
|
||||
- What is executable now?
|
||||
- What capability can perform it?
|
||||
- What evidence is missing?
|
||||
- Should it retry, repair, replan, escalate, or stop?
|
||||
- Has the Work reached a valid terminal state?
|
||||
|
||||
## 16. Initial scope — first product loop
|
||||
Resolver outcomes:
|
||||
|
||||
1. User starts/connects a software project.
|
||||
2. Product establishes project context.
|
||||
3. User describes desired work via global composer.
|
||||
4. System creates/updates a work unit.
|
||||
5. Unit is clarified and accepted.
|
||||
6. System progresses work autonomously.
|
||||
7. User reviews only necessary decisions/outputs.
|
||||
8. System produces verified artifacts.
|
||||
9. User approves publication/integration where required.
|
||||
10. Product updates the unit and retains knowledge.
|
||||
```text
|
||||
VerifiedOutcomeDelivered
|
||||
VerifiedPRReady
|
||||
HumanDecisionRequired
|
||||
ExternalDependencyBlocked
|
||||
BudgetExhaustedWithEvidence
|
||||
PermanentlyFailedWithDiagnosis
|
||||
Cancelled
|
||||
```
|
||||
|
||||
First version must prove persistent work units beat disposable agent chats.
|
||||
The Resolver MUST:
|
||||
|
||||
## 17. Long-term direction
|
||||
- operate from durable state;
|
||||
- execute bounded attempts;
|
||||
- enforce budgets and permissions;
|
||||
- preserve provenance;
|
||||
- recover after process failure;
|
||||
- avoid duplicate side effects;
|
||||
- require evidence before transitions;
|
||||
- surface precise blockers;
|
||||
- never silently stall.
|
||||
|
||||
Technical product is the starting point. The same work-unit model later supports: product research, marketing campaigns, content production, sales enablement, support operations, pricing work, business analysis, hiring, internal ops. Long-term: a general OS for creative/knowledge work.
|
||||
## 7. Human operating model
|
||||
|
||||
**Enduring principles:** one persistent workspace · work units not chat sessions · outcome-oriented execution · invisible orchestration · explicit human authority · strong provenance · compounding organizational knowledge.
|
||||
Humans should spend attention on high-leverage decisions, not supervise tool calls.
|
||||
|
||||
## 18. Initial non-goals
|
||||
Preferred gates:
|
||||
|
||||
Not intended to be: a full external-tool replacement; a general social collaboration platform; a traditional kanban 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; a fully autonomous company with no human authority.
|
||||
- Work Definition approval;
|
||||
- Design Packet approval for standard/critical work;
|
||||
- slice review when risk requires it;
|
||||
- merge/release approval;
|
||||
- resolution of ambiguity or policy exceptions.
|
||||
|
||||
## 19. Principles
|
||||
A human request must include:
|
||||
|
||||
1. Organize around work, not conversations.
|
||||
2. Represent outcomes, not activity.
|
||||
3. Keep the system calm while the machinery stays 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.
|
||||
```text
|
||||
decision needed
|
||||
why it is needed
|
||||
recommended action
|
||||
alternatives
|
||||
consequences
|
||||
urgency
|
||||
affected Work/slice
|
||||
```
|
||||
|
||||
## 20. Working statement
|
||||
## 8. External collaboration
|
||||
|
||||
Zopu Work OS is an autonomous OS for technical founders and small product teams. It observes work across the company, turns fragmented signals into persistent units of work, progresses them via agents and tools, and brings the human in only when judgment, permission, or direction is required. One continuous workspace moves from idea/problem to verified, shipped, measurable outcome while preserving context and building durable understanding over time.
|
||||
Buzz, Slack-like systems, Git forges, monitoring, support, and analytics are interfaces and Signal sources.
|
||||
|
||||
They MAY:
|
||||
|
||||
- create Signals;
|
||||
- carry status updates;
|
||||
- present questions;
|
||||
- receive review/preview links;
|
||||
- report incidents and results.
|
||||
|
||||
They MUST NOT own canonical Work, Resolver, verification, or completion state.
|
||||
|
||||
## 9. Product success metrics
|
||||
|
||||
Primary:
|
||||
|
||||
- verified outcomes per unit of human attention;
|
||||
- median time from accepted Work to verified PR/outcome;
|
||||
- percentage of Work reaching an explicit terminal state;
|
||||
- verification escape rate;
|
||||
- post-merge rework rate;
|
||||
- design-review-to-implementation deviation rate.
|
||||
|
||||
Secondary:
|
||||
|
||||
- retry count;
|
||||
- human interruption count;
|
||||
- stale Work count;
|
||||
- duplicate Signal/Work rate;
|
||||
- average review-package comprehension time;
|
||||
- Kit/version performance by work type.
|
||||
|
||||
Avoid optimizing token volume, agent count, or code generated.
|
||||
|
||||
## 10. Non-goals for early versions
|
||||
|
||||
- Fully autonomous company operation.
|
||||
- Lights-off merging/deployment.
|
||||
- Universal dynamic tool creation.
|
||||
- Large unbounded fleets.
|
||||
- Replacing Git or CI.
|
||||
- Encoding all product truth in chat.
|
||||
- Making one model/harness part of the product domain.
|
||||
- Automating maintainability judgment without human policy.
|
||||
|
||||
Reference in New Issue
Block a user