mirror of
https://github.com/different-ai/openwork
synced 2026-04-25 17:15:34 +02:00
Update PRODUCT.md
This commit is contained in:
290
PRODUCT.md
290
PRODUCT.md
@@ -1,265 +1,49 @@
|
||||
# OpenWork Product
|
||||
## Product
|
||||
|
||||
## Target Users
|
||||
OpenWork helps individual create, consume, and maintain their agentic workflows.
|
||||
|
||||
> Bob the IT guy.
|
||||
Bob might already use opencode, he can setup agents and workflows and share them with his team. The only thing he needs is a way to share this. The way he does is by using OpenWork and creating "workpaces".
|
||||
OpenWork helps companies share their agentic workflows and provision their entire team.
|
||||
|
||||
> Susan in accounting
|
||||
The chat interfaces is where people consume the workflows.
|
||||
|
||||
Susan in accounting doesn't use opencode. She certaintly doesn't paly aorund to create workflow create agents. She wants something that works.
|
||||
Openwork should be given to give her a good taste of what she can do.
|
||||
We should also eventually guide ther to:
|
||||
- creating her own skills
|
||||
- adding custom MCP / login into mcp oauth servers through ui)
|
||||
- adding skills from a list of skills
|
||||
- adding plugins from a list of plugins
|
||||
- create her own commands
|
||||
Interfaces for consuming workflows:
|
||||
- Desktop app
|
||||
- Slack
|
||||
- Telegram
|
||||
|
||||
What is a "agentic workflow":
|
||||
- LLM providers
|
||||
- Skills
|
||||
- MCP
|
||||
- Agents
|
||||
- Plugins
|
||||
- Tools
|
||||
- Background Agents
|
||||
|
||||
Where are workflows created:
|
||||
- Desktop app (using slash commands like `/create-skills`)
|
||||
- Web App
|
||||
- [We need better places for this to happen[
|
||||
|
||||
1. **knowledge worker**: "Do this for me" workflows with guardrails.
|
||||
2. **Mobile-first user**: start/monitor tasks from phone.
|
||||
3. **Power user**: wants UI parity + speed + inspection.
|
||||
4. **Admin/host**: manages a shared machine + profiles.
|
||||
Where are workflows maintain:
|
||||
- In OpenWork Cloud (internal name is Den).
|
||||
|
||||
## Success Metrics
|
||||
Where are workflow hosted:
|
||||
- Local Machine
|
||||
- Remote via a OpenWork Host (CLI or desktop)
|
||||
- Remote on OpenWork Cloud (via Den sandbox workers)
|
||||
|
||||
- < 5 minutes to first successful task on fresh install.
|
||||
- > 80% task success without terminal fallback.
|
||||
- Permission prompts understood/accepted (low confusion + low deny-by-accident).
|
||||
- UI performance: 60fps; <100ms interaction latency; no jank.
|
||||
## Actors
|
||||
Bob IT guy makes the config.
|
||||
Susan the accountant consumes the config.
|
||||
|
||||
## Product Primitives (What OpenWork Exposes)
|
||||
Constraints:
|
||||
- We use standards were possible
|
||||
- We use opencode where possible
|
||||
- We stay platform agnostic
|
||||
|
||||
OpenWork must feel like "OpenCode, but for everyone."
|
||||
|
||||
### 1) Tasks
|
||||
|
||||
- A Task = a user-described outcome.
|
||||
- A Run = an OpenCode session + event stream.
|
||||
|
||||
### 2) Plans / Todo Lists
|
||||
|
||||
OpenWork provides a first-class plan UI:
|
||||
|
||||
- Plan is generated before execution (editable).
|
||||
- Plan is updated during execution (step status + timestamps).
|
||||
- Plan is stored as a structured artifact attached to the session (JSON) so it's reconstructable.
|
||||
|
||||
Implementation detail:
|
||||
|
||||
- The plan is represented in OpenCode as structured `parts` (or a dedicated "plan message") and mirrored in OpenWork.
|
||||
|
||||
### 3) Steps
|
||||
|
||||
- Each tool call becomes a step row with:
|
||||
- tool name
|
||||
- arguments summary
|
||||
- permission state
|
||||
- start/end time
|
||||
- output preview
|
||||
|
||||
### 4) Artifacts
|
||||
|
||||
Artifacts are user-visible outputs:
|
||||
|
||||
- files created/modified
|
||||
- generated documents/spreadsheets/presentations
|
||||
- exported logs and summaries
|
||||
|
||||
OpenWork lists artifacts per run and supports open/share/download.
|
||||
|
||||
### 5) Audit Log
|
||||
|
||||
Every run provides an exportable audit log:
|
||||
|
||||
- prompts
|
||||
- plan
|
||||
- tool calls
|
||||
- permission decisions
|
||||
- outputs
|
||||
|
||||
## UI/UX Requirements (Slick as a Core Goal)
|
||||
|
||||
### Design Targets
|
||||
|
||||
- premium, calm, high-contrast
|
||||
- subtle motion, springy transitions
|
||||
- zero "developer vibes" in default mode
|
||||
|
||||
### Performance Targets
|
||||
|
||||
- 60fps animations
|
||||
- <100ms input-to-feedback
|
||||
- no blocking spinners (always show progress state)
|
||||
|
||||
### Mobile-first Interaction
|
||||
|
||||
- bottom navigation
|
||||
- swipe gestures (dismiss, approve, cancel)
|
||||
- haptics for major events
|
||||
- adaptive layouts (phone/tablet)
|
||||
|
||||
### Accessibility
|
||||
|
||||
- WCAG 2.1 AA
|
||||
- reduced motion mode
|
||||
- screen-reader labels for steps + permissions
|
||||
|
||||
## Design Reference
|
||||
|
||||
use the design from ./design.ts that is your core reference for building the entire ui
|
||||
|
||||
## Functional Requirements
|
||||
|
||||
### Onboarding
|
||||
|
||||
- Host vs Client selection
|
||||
- workspace selection (Host)
|
||||
- connect to host (Client)
|
||||
- provider/model setup
|
||||
- first-run "hello world" task
|
||||
|
||||
### Cloud Worker Onboarding (Current)
|
||||
|
||||
- Sign in (or sign up) on OpenWork cloud control surface.
|
||||
- Launch worker with a human-readable name.
|
||||
- If needed, complete checkout and return.
|
||||
- Select launched worker from list/detail shell.
|
||||
- Connect from OpenWork app via `Add a worker` -> `Connect remote`.
|
||||
- Prefer one-click deep link when available; always provide manual URL + token fallback.
|
||||
|
||||
### Task Execution
|
||||
|
||||
- create task
|
||||
- plan preview and edit
|
||||
- run with streaming updates
|
||||
- pause/resume/cancel
|
||||
- show artifacts and summaries
|
||||
|
||||
### Permissions
|
||||
|
||||
- clear prompts with "why"
|
||||
- allow once/session
|
||||
- audit of decisions
|
||||
|
||||
### Commands
|
||||
|
||||
- save a task as a command
|
||||
- arguments + quick run
|
||||
|
||||
### Scheduling (Future)
|
||||
|
||||
- schedule command runs
|
||||
- notify on completion
|
||||
|
||||
## User Flow Map (Exhaustive)
|
||||
|
||||
### 0. Install & Launch
|
||||
|
||||
1. User installs OpenWork.
|
||||
2. App launches.
|
||||
3. App shows "Choose mode: Host / Client".
|
||||
4. Host: start local OpenCode via SDK.
|
||||
5. Client: connect flow to an existing host.
|
||||
|
||||
### 1. First-Run Onboarding (Host)
|
||||
|
||||
1. Welcome + safety overview.
|
||||
2. Workspace folder selection.
|
||||
3. Allowed folders selection (can be multiple).
|
||||
4. Provider/model configuration.
|
||||
5. `global.health()` check.
|
||||
6. Run a test session using `session.create()` + `session.prompt()`.
|
||||
7. Success + sample commands.
|
||||
|
||||
### 2. Pairing Onboarding (Client / Mobile)
|
||||
|
||||
1. User selects "Client".
|
||||
2. UI explains it connects to a trusted host.
|
||||
3. User scans QR code shown on host device.
|
||||
4. Client verifies connection with `global.health()`.
|
||||
5. Client can now list sessions and monitor runs.
|
||||
|
||||
### 3. Runtime Health & Recovery
|
||||
|
||||
1. UI pings `global.health()`.
|
||||
2. If unhealthy:
|
||||
- Host: attempt restart via `createOpencode()`.
|
||||
- Client: show reconnect + diagnostics.
|
||||
|
||||
### 4. Quick Task Flow
|
||||
|
||||
1. User types goal.
|
||||
2. OpenWork generates plan (structured).
|
||||
3. User approves.
|
||||
4. Create session: `session.create()`.
|
||||
5. Send prompt: `session.prompt()`.
|
||||
6. Subscribe to events: `event.subscribe()`.
|
||||
7. Render streaming output + steps.
|
||||
8. Show artifacts.
|
||||
|
||||
### 5. Guided Task Flow
|
||||
|
||||
1. Wizard collects goal, constraints, outputs.
|
||||
2. Plan preview with "risky step" highlights.
|
||||
3. Run execution with progress UI.
|
||||
|
||||
### 6. File-Driven Task Flow
|
||||
|
||||
1. User attaches files.
|
||||
2. OpenWork injects context into session.
|
||||
3. Execute prompt.
|
||||
|
||||
### 7. Permissions Flow (Any)
|
||||
|
||||
1. Event indicates permission request.
|
||||
2. UI modal shows request.
|
||||
3. User chooses allow/deny.
|
||||
4. UI calls `client.permission.reply({ requestID, reply })`.
|
||||
5. Run continues or fails gracefully.
|
||||
|
||||
### 8. Cancel / Abort
|
||||
|
||||
1. User clicks "Stop".
|
||||
2. UI calls `client.session.abort({ sessionID })`.
|
||||
3. UI marks run stopped.
|
||||
|
||||
### 9. Summarize
|
||||
|
||||
1. User taps "Summarize".
|
||||
2. UI calls `client.session.summarize({ sessionID })`.
|
||||
3. Summary displayed as an artifact.
|
||||
|
||||
### 10. Run History
|
||||
|
||||
1. UI calls `session.list()`.
|
||||
2. Tap a session to load `session.messages()`.
|
||||
3. UI reconstructs plan and steps.
|
||||
|
||||
### 11. File Explorer + Search
|
||||
|
||||
1. User searches: `find.text()`.
|
||||
2. Open file: `file.read()`.
|
||||
3. Show changed files: `file.status()`.
|
||||
|
||||
### 12. Commands
|
||||
|
||||
1. Save a plan + prompt as a command.
|
||||
2. Re-run command creates a new session.
|
||||
|
||||
### 13. Multi-user (Future)
|
||||
|
||||
- separate profiles
|
||||
- separate allowed folders
|
||||
- separate providers/keys
|
||||
|
||||
### 14. Hosted Cloud Worker Connect Flow (Current)
|
||||
|
||||
1. User opens OpenWork cloud control page and authenticates.
|
||||
2. User launches a worker (with optional checkout).
|
||||
3. UI polls until worker is healthy.
|
||||
4. UI resolves workspace-scoped connect URL (`/w/ws_*`) and access token.
|
||||
5. User clicks `Open in OpenWork` or copies manual credentials.
|
||||
6. In OpenWork app, user uses `Add a worker` -> `Connect remote` and starts working.
|
||||
How to decide if OpenWork should do something:
|
||||
- Does it help Bob share config more easily?
|
||||
- Does it help Susan consume automations more easily?
|
||||
- Is this something that is coding specific?
|
||||
|
||||
Reference in New Issue
Block a user