Brainforge Work — Rolling PRD
Owner: Uttam Kumaran Created: 2026-04-29 Last updated: 2026-04-29 Status: active Sources: Miranda Wen’s Product Plan (brainforge-platform PR #660), OpenWork Server PRD, OpenWork Orchestrator PRD, 10x Quality Pass, Usability Refactor Plan, Skill Governance Plan, 2026-04-29 ideation session, 2026-04-29 doc review
1. Product Vision
Brainforge Work provides a unified surface where AI skills become usable products — easy to run, easy to share, easy to govern, and reliable enough for everyday work across teams. It abstracts away underlying complexity so people can execute repeatable workflows faster, more consistently, and at scale.
AI capability is no longer the scarce thing; operational use is. Teams can access strong models and agent workflows, but usage concentrates among experts. Brainforge Work packages expert capability into guided, repeatable, trustworthy workflows that more people can run confidently.
Core Principles
| Principle | Definition |
|---|---|
| Self-explanatory by default | No formal training required; product guidance is built into the UI |
| Repeatable workflow execution | Run the same workflow again without rebuilding |
| Low-support adoption | Pilot users succeed without live walkthroughs |
| Governed delegation | Approvals, sharing controls, audit visibility |
| Workflow reuse across teams | Expert-built workflows used by multiple people |
| Clear operator experience | No specialist toolchains required |
2. Architecture
| Layer | Technology | Notes |
|---|---|---|
| Desktop shell | Tauri 2.x (Rust) | macOS/Windows/Linux, protocol handlers, sidecar management |
| Frontend | SolidJS + TailwindCSS | CUPID domain architecture, DLS tokens mandatory |
| Orchestrator | Node/Bun CLI | Lifecycle supervisor for OpenCode, host/client mode |
| Server | Node/Bun HTTP API | Filesystem-backed API for remote client config |
| OpenCode integration | CLI spawn or embedded binary | Per-workspace isolation, aks key, proxy header routing |
| Auth | demo (dev) / real (production) / agent (CI) | Azure-first providers (Kimi K2.5 + GPT-4o via brainforge-openai) |
| Skills | 200+ skills in .agents/skills/ | File-based, hierarchical precedence (see §4.4), hot-reload |
Runtime Modes
| Mode | Description |
|---|---|
| Desktop-hosted | App runs locally, hosts server + OpenCode engine |
| CLI-hosted | Server surfaces provided by orchestrator on a trusted machine |
| Hosted Cloud | Brainforge-hosted infrastructure provisions workers |
3. Phases & Tracker
Legend: ☐ Not started | ◐ In progress | ★ Deferred | ✓ Complete | ✗ Cancelled
Phase 0: Foundation (Target: 2026-04)
| ID | Deliverable | Status | Notes |
|---|---|---|---|
| P0.1 | Rename to “Brainforge Work” (Tauri config, shell defaults) | ◐ | PRD created, renames applied |
| P0.2 | Landing surface explains what Work is for, who it’s for | ◐ | |
| P0.3 | Basic navigation and startup flow reliable for pilot users | ◐ | |
| P0.4 | Guided First-Run Experience (auto-detect env, zero-config) | ☐ | Merged from ideation I2. Prerequisite: P0.5 must ship first — credentials must be diagnosable before users see the app |
| P0.5 | Model fallback diagnostics (Azure unreachable → clear error) | ☐ | Merged from ideation I7. Blocks P0.4 — credential health check is prerequisite for any user-facing milestone |
| P0.6 | Testing Foundation — Playwright E2E framework + CI matrix | ☐ | See §4.5. Prerequisite: audit CI path filters (packages/** → apps/**) — current filters don’t match monorepo source layout |
| P0.7 | Server unit test coverage audit + gap fill | ☐ | Existing: Bun test, 9 files. Gaps: MCP execution, file ops edge cases. Prerequisite: add bun test job to ci.yml — server tests currently not run in CI |
| P0.8 | Knowledge Repo Viewer — Quartz (MIT) static site for knowledge/, docs/, apps/app/pr/ hosted at knowledge.brainforge.ai via Railway | ☐ | See I16. Supporting infra — does not gate user-facing milestones. GitHub Action rebuild on push to main |
Phase 1: Workflow Productization (Target: 2026-04 to 2026-05)
| ID | Deliverable | Status | Notes |
|---|---|---|---|
| P1.1 | Entry surface reachable without developer-only setup | ☐ | |
| P1.2 | Small fixed set of high-confidence workflows run end-to-end | ☐ | |
| P1.3 | First-run experience does not assume IDE-native behavior | ☐ | |
| P1.4 | Repeat runs of same workflow without rebuilding | ☐ | |
| P1.5 | 10x quality gates met (all Q1-Q10) | ☐ | See §4.3 |
| P1.6 | Skill Conflict Detection — surface silent trigger overwrites | ☐ | Merged from ideation I1 |
| P1.7 | Run Dossiers Completion — search, filter, compare, share | ☐ | Merged from ideation I3 |
| P1.8 | Token Estimate Display — show estimated token count/cost before skill execution | ☐ | Stripped from I4. Full dry-run (sandbox, diff preview) moved to P2.9 |
| P1.9 | Sequential Skill Chaining — “run skill A, then skill B” with output→input passthrough | ☐ | Merged from ideation I5. DAG editor moved to P2.7, gated on P3.2 governance |
| P1.10 | Core Functionality Test Suite — skill use, artifact creation, MCPs, logging | ☐ | See §4.5 |
| P1.11 | Browser walkthrough tests for key user flows | ☐ | See §4.5.3 |
| P1.12 | Pre-push test gate (husky/lefthook) to block regressions | ☐ |
Phase 2: Internal Adoption (Target: 2026-05 to 2026-06)
| ID | Deliverable | Status | Notes |
|---|---|---|---|
| P2.1 | Initial GTM pilot cohort confirmed | ☐ | |
| P2.2 | First workflow set live with clear use cases | ☐ | |
| P2.3 | Self-explanatory first use (no live walkthrough needed) | ☐ | |
| P2.4 | Support burden manageable for pilot scale | ☐ | |
| P2.5 | Strategy/CSO/Delivery workflows identified and scoped | ☐ | |
| P2.6 | Workflow Authoring — skill selection + parameter config + bundle + share as reusable workflow package | ☐ | Addresses P0 gap: product premise requires a creation path |
| P2.7 | Multi-Skill Composition DAG Editor — DAG-based chaining with cue points, fallback branches, handoff contracts | ☐ | Moved from P1.9. Gated on P3.2 governance |
| P2.8 | Workflow Sharing — share-via-link with preview card, team workflow catalog, discover-from-team-members | ☐ | Pairs with P2.6 authoring. Required for workflow reuse metric |
| P2.9 | Skill Preview & Dry-Run Mode — sandboxed execution, diff preview, mock credentials | ☐ | Moved from P1.8. Full dry-run gated on P3.2 governance |
Phase 3: Trust & Governance (Target: 2026-05 to 2026-07)
| ID | Deliverable | Status | Notes |
|---|---|---|---|
| P3.1 | Success metrics observable consistently for pilot users | ☐ | |
| P3.2 | Skill governance: deterministic precedence + conflict surfacing | ☐ | |
| P3.3 | Skill audit tooling + CI guardrails | ☐ | |
| P3.4 | Minimum viable governance: approvals + sharing controls | ☐ | |
| P3.5 | Users report higher confidence in Work vs generic chat | ☐ | |
| P3.6 | Agent Explainability Panel — tool-call transparency | ☐ | Merged from ideation I6 |
Phase 4: Client Delivery (Target: 2026-07 to 2026-09)
| ID | Deliverable | Status | Notes |
|---|---|---|---|
| P4.1 | Internal adoption strong enough for credible case study | ☐ | |
| P4.2 | Services packaging: Work value clear for delivery quality | ☐ | |
| P4.3 | Candidate client workflow categories identified | ☐ | |
| P4.4 | CSO/GTM positioning clear for productized future | ☐ |
4. Detailed Requirements
4.1 Server API
Functional:
- Expose workspace config read/write APIs for
.opencodeandopencode.json - List installed skills, plugins, MCPs without direct FS access
- Allow saving new skills, plugins, MCP entries from remote clients
- Host mode auto-starts OpenWork server alongside OpenCode engine
- Surface pairing URL + tokens in Settings for host mode
- Show remote-config origin, last updated time, and change attribution
API surface: GET /health, GET /workspaces, GET/PATCH /workspace/:id/config, GET/POST /workspace/:id/skills, GET /workspace/:id/plugins, GET /capabilities
Auth model: Write endpoints (PATCH, POST) require a valid pairing token (see §4.2) or session JWT. Read endpoints require a workspace-scoped client identity header. Demo mode (dev) skips auth; real mode enforces. Agent mode uses VITE_AUTH_BRIDGE_SESSION_TOKEN.
Non-goals: Replacing OpenCode’s server, arbitrary filesystem access, multi-tenant hosting
4.2 Orchestrator
Host lifecycle: User picks workspace → OpenWork starts OpenCode → starts server → registers workspace → Settings shows pairing URL + token
Client flow: User enters host URL + token → client calls /health + /workspaces → host returns OpenCode base URL + directory → client connects via SDK
Fallback: Non-OpenWork URLs connect directly to OpenCode. UI shows “Connected via OpenCode (not OpenWork).”
Data model: WorkspaceInfo { id, name, path, workspaceType, remoteType: "openwork" | "opencode", openworkHostUrl?, openworkWorkspaceId?, opencodeBaseUrl?, opencodeDirectory? }
4.3 UX Standards
10x Quality Gates:
| Gate | Requirement | Status |
|---|---|---|
| Q1 | Dashboard data refresh TTL + manual refresh | ◐ |
| Q2 | No debug logs in production (gated behind developerMode()) | ◐ |
| Q3 | Step cluster collapse works consistently in MessageList | ◐ |
| Q4 | Session sidebar shows “Show more” affordance | ◐ |
| Q5 | Context menus never render off-screen | ◐ |
| Q6 | Visibility-aware polling (pause when hidden) | ◐ |
| Q7 | No browser-native prompts (window.confirm/prompt) | ◐ |
| Q8 | Mention search never shows stale results | ◐ |
| Q9 | Inactive workspace session freshness | ◐ |
| Q10 | OpenWork server check backoff when disconnected | ◐ |
Design System: All UI must use DLS tokens. No hardcoded colors, shadows, border radius, or fonts. WCAG 2.1 AA contrast minimum.
Completed UX (from prior refactor):
- ✓
company-devskips chooser when remote worker env present - ✓ Skills renders as discovery catalog, not package manager
- ✓ Remote workspaces only show cloud-compatible integrations
- ✓ Dashboard shell reachable even when backend disconnected
- ✓ Completed runs expose shareable dossier summaries (80%)
4.4 Skill Governance (Planned, Not Implemented)
Precedence model: Project-local (.opencode/skills, .claude/skills, .cursor/skills/*/.opencode/skills) > Repo-discovered (.agents/skills) > Cursor top-level (.cursor/skills/*/SKILL.md) > Global (~/.config/opencode/skills, ~/.claude/skills, ~/.agents/skills)
Conflict handling: Default API returns active skills only (backwards compatible). Opt-in includeConflicts=true returns conflict groups with candidate metadata.
Audit tooling: Scan .agents/skills/**/SKILL.md for duplicates, missing metadata, broken links. Machine-readable JSON + human summary for PR checks.
4.5 Testing Architecture
Current state (audit 2026-04-29):
| Layer | Framework | Test count | Coverage |
|---|---|---|---|
Server (apps/server) | Bun test | 9 files | Validators, tokens, skills, sessions, MCP, file ops, workflows |
Router (apps/opencode-router) | Node node:test | 6 files | Bridge, Slack, Telegram, DB store |
Orchestrator (apps/orchestrator) | Raw scripts | 2 files | CLI routing, file sessions |
Auth (services/openwork-auth) | Vitest | 1 file | Session cookies, middleware |
Share (services/openwork-share) | Node node:test | 3 files | Bundle rendering, packaging |
Web UI (apps/app) | None | 0 files | P0 gap — no unit or component tests |
Desktop (apps/desktop) | None | 0 files | P0 gap — no Rust or integration tests |
| Browser E2E | Puppeteer (scripts only) | ~15 scripts | Health, sessions, chat, UI suite |
| Playwright E2E | Not configured | N/A | Referenced in docs but not implemented |
Key gaps identified:
- No SolidJS component or unit tests (P0)
- No skill execution end-to-end tests (P0)
- No artifact creation/verification tests (P1)
- No MCP tool execution or MCP server management tests (P1)
- No logging infrastructure tests (P1)
- No test coverage measurement (P1)
tests/e2e/directory referenced in docs does not exist (P1)- No pre-push test hooks (P3)
4.5.1 Phase 0: Testing Foundation (P0.6)
Goal: Standardize test framework, establish Playwright E2E, wire CI matrix.
Deliverables:
- Playwright config at repo root with desktop + web + mobile projects
tests/e2e/directory tree with README per AGENTS.md spec- CI matrix (
ci-tests.yml) runs Playwright on ubuntu-22.04 + macos-14 - Coverage measurement (v8/c8) wired to server tests
- Test script naming convention standardized across packages
Framework decisions:
- Browser E2E (Layer 1 — Regression): Playwright (replacing ad-hoc Puppeteer scripts). Screenshot, trace, video on failure. Deterministic pass/fail for CI.
- Server unit: Bun test (keep). Fast, native TypeScript, already established.
- Router integration: Node
node:test(keep). Simpler for CLI/network tests. - Frontend component: Vitest + Solid Testing Library (add). Matches SolidJS ecosystem.
- Desktop:
cargo testfor Rust. Playwright for desktop E2E (launch Tauri binary).
Dual-layer testing model:
| Layer | Test type | Framework | What it verifies | Runs |
|---|---|---|---|---|
| Layer 1 — Structural | Deterministic E2E | Playwright | Did the button render? Did the route load? Are DLS tokens applied? Is the MCP connected? | CI pre-merge (fast) |
| Layer 2 — Semantic | Agent-driven quality | browser-use / Playwright MCP / Cloud MCP | Did the skill produce a correct artifact? Was the output well-reasoned? Is the dossier readable? | Pre-release, nightly, or manual gate |
Layer 2 rationale: Traditional E2E can verify that a skill run completed, but it cannot assess whether the output is correct. Agent-based browsers (browser-use, Playwright MCP, Claude Computer Use) can inspect the result page and apply judgment — “does this legal review flag the right risks?” — in a way static assertions cannot. This directly enables the Adversarial Output Review ideation idea (I9).
Layer 2 candidate tools:
| Tool | Type | Strengths | Weaknesses |
|---|---|---|---|
| browser-use | OSS agent (~50K stars) | Python, task-driven (“review this page”), no test writing | LLM latency, non-deterministic, young |
| Playwright MCP | MCP server | Any LLM can drive Playwright, reuse existing page objects | Token-heavy (~114K/session), Microsoft recommends CLI over MCP |
| Cloud-browser MCP (peta.io) | Token-efficient MCP | Cuts tokens from ~114K to ~5K per session | Single vendor, new |
| Claude Computer Use | First-party Anthropic | Production-grade, built into API | Expensive per action, API-only |
| QA Studio | Record-to-code | OSS, press record, generates Playwright tests | Early, not semantic judgment |
Recommendation: Start with browser-use for Layer 2 (OSS, active community, Python — easy to script as a pre-release gate on the orchestrator stack). Graduate to Playwright MCP + Cloud MCP for tighter integration if token cost becomes an issue.
4.5.2 Phase 1: Core Functionality Test Suite (P1.10)
| Test Category | What to Test | Framework | Layer | Priority |
|---|---|---|---|---|
| Skill use | Install a skill → list skills → trigger skill → verify completion | Playwright E2E + server unit | L1 | P0 |
| Skill quality | Run skill → agent inspects output for correctness | browser-use / Playwright MCP | L2 | P1 |
| Artifact creation | Run creates dossier → Playwright verifies dossier appears, is searchable | Playwright E2E | L1 | P1 |
| Artifact quality | Agent inspects dossier readability, completeness, format correctness | browser-use | L2 | P2 |
| Core MCPs | Connect MCP → list MCP tools → invoke tool → verify response returned | Playwright E2E + server integration | L1 | P0 |
| MCP output quality | Agent verifies MCP tool response is valid | browser-use | L2 | P2 |
| Logging | Trigger error paths → verify structured log output → verify no secrets in logs | Server unit + smoke | L1 | P1 |
| Session CRUD | Create session → send prompt → receive response → list messages → delete | Playwright E2E + existing scripts | L1 | P0 |
| Auth flow | demo mode → real mode → agent mode → verify token lifecycle | Vitest (existing) + Playwright | L1 | P1 |
| Desktop (Tauri) | Launch app → connect worker → run skill → verify window state | Playwright desktop E2E | L1 | P1 |
| Connectors | Slack → Telegram → verify adapter message flow | Node test (existing) + integration | L1 | P1 |
| Orchestrator | Host mode startup → client connect → workspace switch → fallback path | Orchestrator scripts + Playwright | L1 | P1 |
4.5.3 Browser Walkthrough Tests (P1.11)
| Flow | Steps | Framework |
|---|---|---|
| First launch | Open app → verify dashboard renders → verify no errors in console → verify connection status | Playwright |
| Skill discovery | Navigate to Skills → verify catalog renders → search → verify results → click skill → verify detail view | Playwright |
| Run a skill | Select skill → fill inputs → click run → verify streaming response → verify “complete” state → verify dossier entry created | Playwright |
| MCP management | Navigate to Integrations → add MCP → verify in list → connect → disconnect → remove | Playwright |
| Settings flow | Open settings → change model → verify persists → change theme → verify DLS applied | Playwright |
| Error recovery | Kill server → verify diagnostic shows → restart server → verify auto-reconnect | Playwright |
| Desktop-specific | Open Tauri window → verify title “Brainforge Work” → verify menu actions → verify Cmd+Q → verify re-open | Playwright desktop |
4.5.4 CI Gates
- Pre-merge (Layer 1 only):
ci.ymlruns server Bun tests + auth Vitest tests + Playwright structural E2E + security guards. Must pass in <5 min. - E2E matrix:
ci-tests.ymlruns Playwright suite on ubuntu-22.04 + macos-14 - Desktop build:
build-desktop.ymladdscargo testbefore build - Pre-push hook (P1.12): Run server tests + lint on
git push. Full E2E on CI only. - Pre-release / nightly (Layer 2): Agent-driven quality gate runs skill quality + artifact quality + MCP output quality tests via browser-use CLI. Results posted as PR comment or Slack. Not a merge block (non-deterministic), but a quality signal.
4.6 Feature Spec Inventory
Note: 11 unstarted items need triage — each should be assigned to a phase or marked cancelled. Items that duplicate phase tracker deliverables should be merged in.
| Spec | Description | Status | Triage |
|---|---|---|---|
plugin-endpoints.md | Plugin config via /config API endpoint | ☐ | — |
reload-toast-persist.md | Reload toast persists across navigation | ☐ | — |
browser-entry-button.md | Browser entry button in UI | ☐ | — |
skill-creator-triggers.md | Trigger rules for skill creator | ☐ | — |
notion-connection-fix.md | Notion connection fix | ☐ | — |
steps-composer-docked.md | Docked steps composer UX | ☐ | — |
cmdk-session-model-thinking.md | CMD+K for model/thinking settings | ☐ | — |
OpenCode Server.md | OpenCode server integration | ☐ | — |
session-view-sans-font.md | Session view font specification | ☐ | — |
always-open-new-session.md | Always open new session on boot | ✓ | — |
context-panel-ux.md | Context panel UX improvements | ✓ | — |
session-flow-humanized.md | Session flow human narrative pass | ✓ | — |
orbita-layout-ui.md | Orbita layout UI refresh | ✓ | — |
multi-workspace-config.md | Multi-workspace config | ☐ | — |
openwork-orchestrator-multi-workspace.md | Orchestrator multi-workspace | ☐ | — |
telegram-private-bot-pairing.md | Telegram private bot pairing | ☐ | — |
4.7 Design Decisions (Resolved from Review 2026-04-29)
Interaction states per surface:
| Surface | Loading | Empty | Error | Populated |
|---|---|---|---|---|
| Skills catalog | Skeleton card grid | CTA: “Browse recommended skills” → curated list | Retry button + “Couldn’t load skills” | Searchable card grid |
| MCP/Integrations list | Skeleton rows | CTA: “Add your first integration” | Red dot + retry + “Connection failed” | List with status dots (green/yellow/red) |
| Dashboard | Skeleton widgets | CTA: “Run your first workflow” | Banner: “Worker not reachable — check connection” | Active sessions + metrics |
| Session composer | Idle (empty prompt area) | N/A — always available | Inline: “Message failed to send — retry?” | Streaming → complete |
| Dossiers | Skeleton rows | ”No dossiers yet — run a skill to create one” | Retry button | Searchable + filterable list |
Resolved design decisions:
| Decision | Resolution | Rationale |
|---|---|---|
| Dashboard auto-focus after startup | Focus on active sessions if any exist; otherwise recommended skills | Most users return to ongoing work; new users need discovery |
| Dossier share target (v1) | In-app link with preview card; Markdown export as v2 | Link is zero-friction for internal teams; export is optional |
| Discovery card deep-linking | Cards link to skill detail page (not integration page root) | Users click cards to learn about the skill, not manage infrastructure |
| Self-explanatory mechanism | Inline tooltips on first visit + empty-state CTAs | Simpler than guided overlay; pairs with P0.4 first-run checklist |
| First-run flow | 3-step: Welcome → Scan (“Checking your setup…”) → Ready (“Everything looks good — start here”) | Single-screen with progress; no multi-page wizard |
| Multi-skill composition UX | Deferred to Phase 2 exploration. Phase 1: sequential chaining only (“run skill A, then skill B”) | DAG editor is High complexity; sequence-first lets single-skill workflows prove value |
| Dossier search + filter interaction | Dropdown chips: outcome + date range + skill-name autocomplete. Comparison: side-by-side diff | Resolves I3 remaining 20% |
5. Success Metrics
| Metric | Target | Current |
|---|---|---|
| First-run workflow completion | >=40% of pilot users complete meaningful workflow on first run | — |
| Return usage | >=70% return to run a second workflow | — |
| Time-to-first-success | Median < 4 minutes from first visit to completion | — |
| Self-service adoption | >=80% complete first workflow without live walkthrough | — |
| Trust vs generic chat | >=70% report Work feels more trustworthy than generic chat | — |
| Workflow reuse | >=2 expert-built workflows reused by 3+ users | — |
| Weekly active users | >=80% of target pilot users are weekly active | — |
| Input-to-feedback latency | < 100ms on session and dashboard actions | — |
| Stale-dashboard regressions | 0 in repeated navigation | — |
6. Risk Register
| Risk | Severity | Mitigation |
|---|---|---|
| Workflow quality inconsistent early on | Medium | Narrow set of high-confidence workflows; quality bar before expanding |
| Product feels too technical for non-IDE users | High | Prioritize onboarding clarity, guided inputs, simpler outputs |
| Governance friction slows adoption | Medium | Minimum viable governance first; increase controls only where needed |
| Success depends on narrow workflow set | Medium | Focused pilot catalog; expand only after reuse signals clear |
| Too much live explanation needed | High | Low-training usability as product requirement; support effort as core signal |
| Skill precedence change alters active resolution | Low | Ship with conflict surfacing; temporary allowlist for known duplicates |
| Remote startup conflicts with persisted local preference | Medium | Centralize remote-worker signal; prefer env-driven path in company-dev |
| Azure credential fragility (silent dead app) | High | Model fallback diagnostics (P0.5); credential health check on startup |
7. Running Ideas
| ID | Idea | Conviction | Complexity | Phase | Status |
|---|---|---|---|---|---|
| I1 | Skill Conflict Detection & Resolution — surface silent trigger overwrites, conflict dashboard, dead skill janitor | High | Med | 1→3 | Unexplored |
| I2 | Guided First-Run Experience — auto-detect env, zero-config cold start, one-screen checklist | High | Low-Med | 0 | Unexplored |
| I3 | Run Dossiers Completion — search, filter by outcome, compare runs, share via link | High | Low | 1→2 | Explored — 80% implemented |
| I4 | Skill Preview & Dry-Run Mode — sandboxed execution, cost estimate, diff preview, mock credentials | High | Med-High | 1→3 | Unexplored |
| I5 | Multi-Skill Composition — now scoped as sequential chaining (P1.9); DAG editor moved to P2.7 | Med | High | 1→2 | Explored — scoped down from review |
| I6 | Agent Explainability Panel — tool-call transparency, decision trace, failure visibility | High | Med | 3 | Unexplored |
| I7 | Model Fallback & Graceful Degradation — Azure-unreachable diagnostics, provider fallback hints, credential health | High | Low | 0→1 | Unexplored |
| I8 | Session-to-Skill Compiler — observe manual runs, auto-generate reusable skill from trace | Med | Med | 2 | Unexplored |
| I9 | Adversarial Output Review — second-agent critique on every output, confidence scoring | Med | High | 3 | Deferred |
| I10 | Skill Telemetry & Scorecard — per-skill analytics | Med | Med | 3 | Deferred |
| I11 | Universal Deep-Link Handshake — one-click workspace provisioning | Med | Med | 2 | Deferred |
| I12 | Adaptive Onboarding Engine — role-aware skill suggestions | Low | High | 2 | Deferred |
| I13 | Continuous Work Stream — no sessions, infinite timeline | Low | High | 3+ | Deferred |
| I14 | Offline-First Peer-to-Peer — local models, zero cloud | Low | High | 4+ | Deferred |
| I15 | Voice/Mobile-First — WhatsApp/Telegram connector | Low | High | 4+ | Deferred |
| I16 | Knowledge Repo Viewer — Quartz (MIT, 12K★) static site at knowledge.brainforge.ai via Railway | High | Low-Med | 0 | Decided — Quartz on Railway (P0.8) |
8. Source Documents
| Document | Location | Notes |
|---|---|---|
| Miranda Wen Product Plan | brainforge-platform: knowledge/engineering/openwork-platform-integration/brainforge-work-product-plan.md | Strategic vision, 4 initiatives, milestones |
| OpenWork Server PRD | apps/app/pr/openwork-server.md | Server API design (804 lines) |
| OpenWork Orchestrator PRD | apps/app/pr/openwork-orchestrator.md | Host/client mode, fallback, data model |
| 10x Quality Pass | apps/app/pr/openwork-10x.md | P0 quality gates (Q1-Q10) |
| 10x Quality Audit | apps/app/pr/openwork-10x-audit.md | Companion audit findings |
| Usability Refactor Plan | docs/plans/2026-04-18-001-refactor-openwork-usability-and-design-plan.md | 6-unit UX refactor (complete) |
| Skill Governance Plan | docs/plans/2026-04-20-001-feat-skill-governance-and-discovery-plan.md | 5 units (not implemented) |
| Design Refresh DLS | docs/plans/2026-04-24-design-refresh-dls-normalization.md | Token normalization notes |
| Work Guides Overlay | docs/plans/2026-04-24-002-brainforge-work-guides-overlay-implementation-plan.md | Overlay walkthrough V1 |
| + 12 feature specs | apps/app/pr/*.md | Individual feature-level specs |
9. Deferred / Open Questions
From 2026-04-29 doc review (P1 — security gaps):
| # | Finding | Why deferred |
|---|---|---|
| Q1 | Pairing token security — generation algorithm, entropy, expiry, rotation, revocation not specified | Requires dedicated security design pass beyond PRD scope |
| Q2 | Credential management — no secrets storage strategy, rotation policy, or compromise procedure | Depends on infrastructure decisions (env vars vs vault vs managed secrets) |
| Q3 | Data classification — no policy for sensitive data handling, retention/deletion, or trust boundary crossings | Needs stakeholder agreement on data sensitivity tiers |
| Q4 | Input validation — POST endpoints lack schema enforcement, path traversal prevention, rate limiting | Implementable as standard controls; deferred to implementation phase with security review gate |
Resolution: Address in Phase 1 implementation with a dedicated security review gate before any write endpoint ships to users.