Delete pr directory
@@ -1,12 +0,0 @@
|
||||
# Issue 517 - Workspace + Session Deletion
|
||||
|
||||
This PR adds deletion primitives for workspaces + sessions, and exposes session deletion in the main UI.
|
||||
|
||||
## Screenshots
|
||||
|
||||
- Session deletion confirm modal:
|
||||
- `pr/517-workspace-session-deletion/screenshots/session-delete-confirm-final.png`
|
||||
- Session deleted (routed back to /session):
|
||||
- `pr/517-workspace-session-deletion/screenshots/session-delete-after.png`
|
||||
- Toy UI showing delete actions:
|
||||
- `pr/517-workspace-session-deletion/screenshots/toy-ui-delete-buttons.png`
|
||||
|
Before Width: | Height: | Size: 209 KiB |
|
Before Width: | Height: | Size: 327 KiB |
|
Before Width: | Height: | Size: 231 KiB |
|
Before Width: | Height: | Size: 67 KiB |
|
Before Width: | Height: | Size: 446 KiB |
|
Before Width: | Height: | Size: 447 KiB |
|
Before Width: | Height: | Size: 632 KiB |
|
Before Width: | Height: | Size: 1.3 MiB |
|
Before Width: | Height: | Size: 1.7 MiB |
|
Before Width: | Height: | Size: 442 KiB |
@@ -1,12 +0,0 @@
|
||||
flowchart TD
|
||||
A[OpenWork app\nWorkspace configured] --> B[Share modal]
|
||||
B --> C[Create share link]
|
||||
C --> D[Copy link and send]
|
||||
D --> E[Recipient opens URL]
|
||||
E --> F[Share service page]
|
||||
F --> G[Open in OpenWork]
|
||||
G --> H[Deep link with\now_intent=new_worker]
|
||||
H --> I[OpenWork app intercepts]
|
||||
I --> J[Create new worker prompt]
|
||||
J --> K[Provision worker + import bundle]
|
||||
K --> L[Open new session]
|
||||
@@ -1,13 +0,0 @@
|
||||
flowchart TD
|
||||
A[Share service page loaded] --> B{Open in OpenWork clicked}
|
||||
B --> C[Build deep link:\now_bundle + ow_intent=new_worker]
|
||||
C --> D[OS hands URL to OpenWork]
|
||||
D --> E[Parse bundle + intent]
|
||||
E --> F[Wizard: New worker from shared setup]
|
||||
F --> G{Worker target}
|
||||
G -->|Local host| H[Create local worker entry]
|
||||
G -->|Remote host| I[Create remote worker entry]
|
||||
H --> J[Import bundle]
|
||||
I --> J
|
||||
J --> K[Set new worker active]
|
||||
K --> L[Open chat/session]
|
||||
@@ -1,12 +0,0 @@
|
||||
flowchart TD
|
||||
A[OpenWork app share modal] --> B{Add to organization library}
|
||||
B -->|No| C[Direct link sharing only\nfree/default]
|
||||
B -->|Yes| D[Publish metadata + tags\nto org hub]
|
||||
D --> E[Org hub card points to same bundle]
|
||||
E --> F[Teammate opens org hub]
|
||||
F --> G[Open card details]
|
||||
G --> H[Open in OpenWork]
|
||||
H --> I[Deep link with org context\now_source=org_hub]
|
||||
I --> J[OpenWork creates new worker\nand imports bundle]
|
||||
C --> K[Recipient can still open\nshare URL directly]
|
||||
K --> J
|
||||
@@ -1,10 +0,0 @@
|
||||
flowchart TD
|
||||
A[New worker created from shared bundle] --> B[User edits skills/config/commands]
|
||||
B --> C{Share changes}
|
||||
C -->|Fork as new setup| D[Publish new bundle ID]
|
||||
C -->|Update org template| E[Publish next version\nsame template identity]
|
||||
D --> F[New standalone share link]
|
||||
E --> G[Org card now resolves\nto latest approved version]
|
||||
F --> H[Others open as new worker]
|
||||
G --> H
|
||||
H --> I[More remixes and team reuse]
|
||||
|
Before Width: | Height: | Size: 257 KiB |
|
Before Width: | Height: | Size: 240 KiB |
|
Before Width: | Height: | Size: 788 KiB |
|
Before Width: | Height: | Size: 516 KiB |
|
Before Width: | Height: | Size: 92 KiB |
|
Before Width: | Height: | Size: 80 KiB |
|
Before Width: | Height: | Size: 52 KiB |
|
Before Width: | Height: | Size: 53 KiB |
|
Before Width: | Height: | Size: 53 KiB |
|
Before Width: | Height: | Size: 54 KiB |
@@ -1,51 +0,0 @@
|
||||
## Opencode DB Migration Recovery - verification guide
|
||||
|
||||
### What changed
|
||||
|
||||
- Added a desktop command to run `opencode db migrate` from OpenWork.
|
||||
- Added workspace recovery flow to stop engine, migrate, and restart once.
|
||||
- Added onboarding and settings UI entry points for "Fix migration".
|
||||
- Increased first local boot health timeout for `host-start` and `bootstrap-local`.
|
||||
|
||||
### Screenshots in this folder
|
||||
|
||||
- `session-smoke-response.png`
|
||||
- `settings-general.png`
|
||||
- `settings-advanced.png`
|
||||
|
||||
Note: this environment was connected to a remote workspace surface, so desktop-only migration controls were not rendered in Chrome MCP screenshots.
|
||||
|
||||
### Third-party test steps
|
||||
|
||||
1. Install dependencies and validate builds.
|
||||
|
||||
```bash
|
||||
pnpm install
|
||||
pnpm --filter @different-ai/openwork-ui typecheck
|
||||
pnpm --filter @different-ai/openwork-ui build
|
||||
pnpm --filter @different-ai/openwork-desktop tauri build --debug
|
||||
```
|
||||
|
||||
2. Run desktop app and verify recovery action appears.
|
||||
|
||||
```bash
|
||||
pnpm --filter @different-ai/openwork-desktop tauri dev
|
||||
```
|
||||
|
||||
3. In the desktop app, create or open a local workspace and force local startup preference.
|
||||
|
||||
4. Trigger a migration failure scenario (example: use an older `opencode` binary or stale `.opencode/opencode.db` schema), then confirm:
|
||||
- onboarding error panel shows `Fix migration`
|
||||
- settings -> Advanced shows `Migration recovery`
|
||||
- clicking `Fix migration` runs migrate, then retries local start once
|
||||
|
||||
5. Confirm fallback copy for older CLIs without `db migrate`:
|
||||
- expected message points user to upgrading OpenCode.
|
||||
|
||||
6. Optional Docker + Chrome MCP gate for UI sanity:
|
||||
|
||||
```bash
|
||||
packaging/docker/dev-up.sh
|
||||
```
|
||||
|
||||
Use the printed Web UI URL, run one smoke prompt/response flow, then stop with the printed `docker compose -p ... down` command.
|
||||
|
Before Width: | Height: | Size: 442 KiB |
|
Before Width: | Height: | Size: 414 KiB |
|
Before Width: | Height: | Size: 56 KiB |
@@ -1,18 +0,0 @@
|
||||
## Validation
|
||||
|
||||
- `pnpm --filter @different-ai/openwork-ui typecheck` (pass)
|
||||
- `pnpm --filter @different-ai/openwork-ui build` (pass)
|
||||
- `pnpm --filter @different-ai/openwork-ui test:health` (fails in this environment: `Timed out waiting for /global/health: Unauthorized`)
|
||||
|
||||
## End-to-end gate
|
||||
|
||||
- Started Docker stack with `packaging/docker/dev-up.sh`
|
||||
- Verified live UI flow via Chrome MCP at `http://localhost:52357/session`
|
||||
- Sent prompt: `smoke: hello from chrome mcp`
|
||||
- Confirmed assistant response: `Hello! How can I help you today?`
|
||||
- Screenshot: `pr/restart-local-server/chrome-mcp-smoke.png`
|
||||
|
||||
## Feature-specific note
|
||||
|
||||
- This change adds a desktop local-host restart action in Settings.
|
||||
- The Docker/Web flow verifies app-server integration health; the restart action itself is desktop-only (Tauri runtime).
|
||||
@@ -1,79 +0,0 @@
|
||||
# Seamless Share Flow Redesign (Free + Org)
|
||||
|
||||
## Product direction
|
||||
|
||||
- Free/default sharing remains the baseline experience.
|
||||
- Organization is an optional index and permission layer on top of the exact same share links.
|
||||
- One bundle format works everywhere (direct link, share service page, org hub card).
|
||||
|
||||
## Core UX rules
|
||||
|
||||
1. Every shared link must be usable directly, even without org membership.
|
||||
2. `Open in OpenWork` from the share service should default to creating a new worker.
|
||||
3. Importing into the current worker remains available as a secondary action.
|
||||
4. Organization does not replace sharing, it organizes and governs the same assets.
|
||||
|
||||
## Deep-link contract
|
||||
|
||||
Proposed URL pattern used by share page and org hub:
|
||||
|
||||
```
|
||||
openwork://import-bundle?ow_bundle=<encoded-share-url>&ow_intent=new_worker&ow_source=<share_service|org_hub>&ow_org=<optional-org-id>&ow_label=<optional-template-name>
|
||||
```
|
||||
|
||||
Supported intents:
|
||||
|
||||
- `ow_intent=new_worker` (default): create a fresh worker and import bundle into it.
|
||||
- `ow_intent=import_current`: import bundle into currently active worker.
|
||||
|
||||
## UI wiring
|
||||
|
||||
### OpenWork app: Share modal
|
||||
|
||||
- Primary action: `Create share link`
|
||||
- Visibility chip:
|
||||
- `Anyone with link` (default, free-friendly)
|
||||
- `Add to organization` (optional)
|
||||
- Destination controls:
|
||||
- `Open in OpenWork -> New worker` (default recipient behavior)
|
||||
- `Import into current worker` (secondary)
|
||||
|
||||
### Share service page
|
||||
|
||||
- Primary CTA: `Open in OpenWork (new worker)`
|
||||
- Secondary CTA: `Import into current worker`
|
||||
- Optional CTA: `Add to organization library` (visible only for signed-in org users)
|
||||
|
||||
### Organization hub (web app)
|
||||
|
||||
- Library is a central index of the same share artifacts:
|
||||
- Search by team, tags, owner, recency.
|
||||
- Open card -> same share detail model + Open in OpenWork deep link.
|
||||
- Org ACL controls discovery and publishing, not bundle compatibility.
|
||||
|
||||
## Flowchart set
|
||||
|
||||
- `pr/diagrams/share-flow-redesign/01-free-default-share.mmd`
|
||||
- `pr/diagrams/share-flow-redesign/02-open-in-app-new-worker.mmd`
|
||||
- `pr/diagrams/share-flow-redesign/03-org-library-overlay.mmd`
|
||||
- `pr/diagrams/share-flow-redesign/04-remix-and-versioning.mmd`
|
||||
|
||||
Rendered PNGs:
|
||||
|
||||
- `evidence/share-flow-redesign/01-free-default-share.png`
|
||||
- `evidence/share-flow-redesign/02-open-in-app-new-worker.png`
|
||||
- `evidence/share-flow-redesign/03-org-library-overlay.png`
|
||||
- `evidence/share-flow-redesign/04-remix-and-versioning.png`
|
||||
- `evidence/share-flow-redesign/share-flow-overview.png` (single sheet with all four flows)
|
||||
|
||||
Video walkthrough:
|
||||
|
||||
- `evidence/share-flow-redesign/share-flow-walkthrough.mp4`
|
||||
|
||||
## Acceptance checklist
|
||||
|
||||
- Direct link share works with no org context.
|
||||
- Share page opens deep link with `ow_intent=new_worker` by default.
|
||||
- OpenWork app deep-link handler can branch by intent.
|
||||
- New worker provisioning path reuses existing remote/local worker creation flow.
|
||||
- Org hub card launch and direct share URL launch land in equivalent app import UX.
|
||||
|
Before Width: | Height: | Size: 351 KiB |
|
Before Width: | Height: | Size: 307 KiB |
|
Before Width: | Height: | Size: 299 KiB |
|
Before Width: | Height: | Size: 289 KiB |
|
Before Width: | Height: | Size: 319 KiB |
|
Before Width: | Height: | Size: 323 KiB |
@@ -1,26 +0,0 @@
|
||||
# Soul Starter Observability + Steering
|
||||
|
||||
## What changed
|
||||
|
||||
- Updated the bundled `give-me-a-soul` starter template to seed memory from real workspace context (AGENTS + sessions + todos + transcript snippets) instead of empty placeholders.
|
||||
- Expanded the starter to create explicit interaction/observability commands (`soul-status`, `steer-soul`) alongside `soul-heartbeat` and `take-my-soul-back`.
|
||||
- Strengthened Soul dashboard steering prompts so they explicitly pull from `.opencode/soul.md`, AGENTS guidance, and OpenCode sqlite activity.
|
||||
- Added an **Improvement sweep** action in the Soul dashboard.
|
||||
- Changed **Enable soul mode** on the Soul dashboard to inject the full bundled starter template prompt.
|
||||
|
||||
## Why
|
||||
|
||||
- Soul mode check-ins were becoming stale/generic because the starter flow often left memory under-seeded.
|
||||
- Users needed a clearer, built-in way to observe and steer Soul behavior without ad-hoc prompting.
|
||||
|
||||
## Evidence
|
||||
|
||||
- `pr/soul-starter-observability/evidence/soul-dashboard-steering.png`
|
||||
- `pr/soul-starter-observability/evidence/session-enable-soul-prefilled.png`
|
||||
|
||||
## Validation
|
||||
|
||||
- `pnpm --filter @different-ai/openwork-ui typecheck`
|
||||
- `pnpm --filter @different-ai/openwork-ui test:health`
|
||||
- Brought up Docker stack for manual verification: `packaging/docker/dev-up.sh`
|
||||
- Verified Soul dashboard renders new controls and state card in browser, then shut stack down.
|
||||
|
Before Width: | Height: | Size: 106 KiB |
|
Before Width: | Height: | Size: 115 KiB |
|
Before Width: | Height: | Size: 233 KiB |
|
Before Width: | Height: | Size: 95 KiB |
|
Before Width: | Height: | Size: 95 KiB |
@@ -1,116 +0,0 @@
|
||||
# Web-Only Mode + Resilient Workspaces PRD
|
||||
|
||||
## Summary
|
||||
Enable OpenWork to run fully in a browser without the Tauri shell, extract shared UI components for web views, and make core flows resilient when no working directory is available. This PRD defines the product shape, user experience, and architectural shifts required to maintain parity with OpenCode primitives while expanding access to web and mobile environments.
|
||||
|
||||
## Goals
|
||||
- Deliver a web-only runtime that does not require the Tauri browser.
|
||||
- Extract shared UI components so views are reusable across web and desktop.
|
||||
- Allow users to start tasks without a working directory and recover when one is missing.
|
||||
- Preserve safety, permissions, and transparency standards from the desktop experience.
|
||||
- Keep UX premium, calm, and mobile-friendly.
|
||||
|
||||
## Non-goals
|
||||
- Replace the Tauri desktop app.
|
||||
- Build a full web IDE or generalized file manager.
|
||||
- Enable fully offline execution without a host or engine.
|
||||
- Add new compute backends beyond OpenCode.
|
||||
|
||||
## Definitions
|
||||
- **Web-only mode**: OpenWork runs in a standard browser, with no Tauri shell.
|
||||
- **Host**: A trusted device running OpenCode that can execute tasks and stream events.
|
||||
- **Workspace**: The authorized folder or project context for tasks.
|
||||
- **No-workspace mode**: Tasks that run without an attached workspace, using minimal context.
|
||||
|
||||
## Guiding principles
|
||||
- Parity with OpenCode primitives (sessions, events, permissions, artifacts).
|
||||
- Least-privilege access with explicit user intent.
|
||||
- Calm, clear UX with minimal jargon.
|
||||
- Graceful degradation when access or connectivity is missing.
|
||||
- Single codepath for UI, with platform-specific adapters.
|
||||
|
||||
## Current state / problem
|
||||
- OpenWork is tightly coupled to Tauri runtime expectations, limiting web-only execution.
|
||||
- Several UI components assume local filesystem access and a working directory.
|
||||
- When a working directory is missing, flows break or block instead of degrading.
|
||||
- Component reuse across web and desktop is limited by platform-specific dependencies.
|
||||
|
||||
## Proposal
|
||||
### 1) Web-only runtime
|
||||
- Introduce a browser runtime mode that connects to an OpenCode host via a secure bridge.
|
||||
- Detect runtime capabilities at launch (web-only, web+host, desktop).
|
||||
- Gate features and show capability badges based on runtime.
|
||||
|
||||
### 2) Shared component extraction
|
||||
- Create a platform-agnostic UI layer for:
|
||||
- task composer
|
||||
- session timeline
|
||||
- permissions prompts
|
||||
- artifacts list
|
||||
- templates and history views
|
||||
- Move platform bindings (filesystem, IPC, process control) to adapters.
|
||||
|
||||
### 3) No-workspace resilience
|
||||
- Support task creation without a workspace.
|
||||
- Only require a workspace when tasks explicitly need filesystem access.
|
||||
- Provide fallback options:
|
||||
- connect a workspace later
|
||||
- use a sample workspace
|
||||
- run in view-only mode
|
||||
|
||||
### 4) Safety and permissions in web-only mode
|
||||
- Default to read-only or no-file access in the browser.
|
||||
- Require explicit approval for host connections and workspace access.
|
||||
- Provide clear “why” explanations for permission requests.
|
||||
|
||||
## UX / flows
|
||||
### Entry (web-only)
|
||||
1. User opens OpenWork in browser.
|
||||
2. Runtime banner indicates “Web Mode”.
|
||||
3. User chooses:
|
||||
- Connect to a host
|
||||
- Continue without workspace
|
||||
4. App lands in a task-ready home view with clear status.
|
||||
|
||||
### No-workspace task flow
|
||||
1. User starts a task without workspace.
|
||||
2. UI shows a “limited context” tag with explanation.
|
||||
3. If the task requires files, prompt to attach or connect workspace.
|
||||
4. Task continues or is paused until workspace is provided.
|
||||
|
||||
### Host connection flow
|
||||
1. User selects “Connect to host.”
|
||||
2. QR / token flow establishes secure connection.
|
||||
3. Health check runs (global.health).
|
||||
4. User can access sessions and run tasks.
|
||||
|
||||
### Permission flow
|
||||
1. Permission request appears with context and scope.
|
||||
2. Options: allow once, allow for session, deny.
|
||||
3. Audit log records decision.
|
||||
|
||||
## Data / storage
|
||||
- Web-only mode stores UI state + session metadata in IndexedDB.
|
||||
- Full session history can be synced from host when connected.
|
||||
- Artifacts remain on host unless explicitly exported or shared.
|
||||
- Clear messaging on where data lives (browser vs host).
|
||||
|
||||
## Migration
|
||||
- Introduce runtime detection without breaking desktop defaults.
|
||||
- Add adapter interfaces and migrate components incrementally.
|
||||
- Keep desktop experience unchanged while enabling web-only parity.
|
||||
|
||||
## Acceptance criteria
|
||||
1. OpenWork runs in a browser with no Tauri dependencies.
|
||||
2. Core task flow works without a workspace, with clear limitations.
|
||||
3. Users can connect to a host and run sessions end-to-end.
|
||||
4. Components render identically across web and desktop for shared views.
|
||||
5. Permission prompts and audit logs work in web-only mode.
|
||||
6. No-workspace paths never hard-block; they guide users forward.
|
||||
|
||||
## Open questions
|
||||
1. Should the host bridge be LAN-only or allow optional tunneling?
|
||||
2. How is authentication handled for shared or public web clients?
|
||||
3. What is the minimal task set that must support no-workspace mode?
|
||||
4. How should large artifacts be exported in web-only mode?
|
||||
5. What is the best fallback when host is unreachable mid-session?
|
||||
@@ -1,15 +0,0 @@
|
||||
# Open In App Connect Flow
|
||||
|
||||
This change adds an **Open in App** connect path in the cloud web panel and makes the OpenWork app web runtime accept `http(s)://.../connect-remote` URLs with worker credentials.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Remote connect URL auto-loaded into the app workspace:
|
||||
- `pr/web-open-in-app/remote-connect-autoload.png`
|
||||
- Vercel-hosted OpenWork UI accepts `/connect-remote` and pre-fills worker fields:
|
||||
- `pr/web-open-in-app/vercel-openwork-ui-connect-remote.png`
|
||||
|
||||
## Vercel Deployments
|
||||
|
||||
- OpenWork UI app (Vite, `packages/app`): `https://openwork-ui-ten.vercel.app`
|
||||
- OpenWork cloud panel preview (Next.js, `packages/web`): `https://openwork-o08livyb6-prologe.vercel.app`
|
||||
|
Before Width: | Height: | Size: 269 KiB |
|
Before Width: | Height: | Size: 284 KiB |
@@ -1,14 +0,0 @@
|
||||
|
||||
> openwork-orchestrator@0.11.127 test:files /Users/benjaminshafii/openwork-enterprise/_worktrees/openwork-worker-files-jit-sync/packages/orchestrator
|
||||
> pnpm build && node scripts/files-session.mjs
|
||||
|
||||
|
||||
> openwork-orchestrator@0.11.127 build /Users/benjaminshafii/openwork-enterprise/_worktrees/openwork-worker-files-jit-sync/packages/orchestrator
|
||||
> tsc -p tsconfig.json
|
||||
|
||||
{
|
||||
"ok": true,
|
||||
"openworkUrl": "http://127.0.0.1:52876",
|
||||
"workspaceId": "ws_9c77bb26ca53",
|
||||
"sessionId": "27effa8d-4958-48e6-a520-9b2fe6f9e1a0"
|
||||
}
|
||||
|
Before Width: | Height: | Size: 158 KiB |