diff --git a/.env.example b/.env.example
new file mode 100644
index 00000000..eddadb61
--- /dev/null
+++ b/.env.example
@@ -0,0 +1,6 @@
+AGENTCOMPANY_UPDATE_URL=
+AGENTCOMPANY_DISABLE_UPDATES=true
+CSC_LINK=
+CSC_KEY_PASSWORD=
+WIN_CSC_LINK=
+WIN_CSC_KEY_PASSWORD=
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 00000000..e758b008
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,33 @@
+# Dependencies
+node_modules/
+
+# Build outputs
+out/
+build/
+dist/
+coverage/
+*.tsbuildinfo
+
+# Test artifacts
+test-results/
+playwright-report/
+
+# Environment files
+.env
+.env.local
+.env.*.local
+
+# Editor and OS files
+.DS_Store
+Thumbs.db
+.idea/
+.vscode/
+
+# Local reference material
+oldreference/
+
+# Package manager logs
+npm-debug.log*
+pnpm-debug.log*
+yarn-debug.log*
+yarn-error.log*
diff --git a/.npmrc b/.npmrc
new file mode 100644
index 00000000..bf2e7648
--- /dev/null
+++ b/.npmrc
@@ -0,0 +1 @@
+shamefully-hoist=true
diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 100644
index 00000000..574e7a36
--- /dev/null
+++ b/CLAUDE.md
@@ -0,0 +1,339 @@
+# AgentCompany Desktop
+
+Cross-platform Electron desktop control plane for local-first AI agent companies.
+
+## Tech Stack
+
+- **Runtime**: Electron 39+, Node 22+ (node:sqlite built-in)
+- **Renderer**: React 19, Tailwind CSS v4, Framer Motion, Phosphor Icons
+- **Fonts**: System stack (-apple-system, Segoe UI, etc.) for body; JetBrains Mono Variable for monospace
+- **State**: useState + IPC full-snapshot refresh pattern
+- **Build**: electron-vite, electron-builder (DMG/NSIS/AppImage)
+- **Validation**: Zod on both IPC sides (main + renderer)
+
+## Design Context
+
+### Users
+
+Technical operators (solo devs, AI-native founders, engineering leads) who run multiple AI coding agents simultaneously via CLI tools like Codex, Claude Code, Kimi CLI, Gemini CLI, and OpenCode. They are power users who think in terms of organizations, budgets, and orchestration - not chat windows. Their context is a focused workstation where this app is the primary command surface for their AI workforce.
+
+### Brand Personality
+
+**Warm, Approachable, Clean** - like Notion meets Raycast. Professional but never cold. The interface should feel like a well-organized workspace run by someone who cares about craft, not a sterile enterprise dashboard. Friendly to newcomers but capable enough for power users.
+
+### Emotional Goal
+
+**Professional authority** - "I'm running a company." The operator should feel like a capable executive at their control surface. Every screen should reinforce that they are in command of their AI organization - seeing status, making decisions, taking action. Not anxious monitoring, but confident oversight.
+
+### Aesthetic Direction
+
+**Primary references**: Linear + Raycast
+- Clean sidebar with grouped navigation
+- Fast keyboard-driven navigation
+- Subtle, purposeful animations (not decorative)
+- Monochrome palette with one warm accent color
+- Information density without clutter
+
+**Anti-references** (what this should NOT look like):
+- Cluttered enterprise dashboards (Jira, ServiceNow)
+- Overly playful / illustration-heavy consumer apps
+- Raw terminal UIs without visual hierarchy
+- Generic Bootstrap/Material admin templates
+
+### Theme Strategy
+
+**System-following** - automatically match OS light/dark preference. Both themes must be maintained. The current light palette is the foundation; dark mode tokens need to be added.
+
+### Color System
+
+| Token | Light | Purpose |
+|---|---|---|
+| `--bg` | `#fbfbfb` | App background |
+| `--panel` | `#ffffff` | Card/sidebar surfaces |
+| `--panel-soft` | `#f4f5f5` | Active/hover states |
+| `--text` | `#1a202c` | Primary text |
+| `--muted` | `#718096` | Secondary/caption text |
+| `--muted-strong` | `#4a5568` | Emphasized secondary text |
+| `--accent` | `#c06a3a` | Warm terracotta - primary action color (~4.6:1 contrast on white) |
+| `--accent-soft` | `#f7ece6` | Accent background tint |
+| `--danger` | `#e5484d` | Errors, destructive actions |
+| `--warn` | `#b7791f` | Warnings, budget alerts |
+| `--success` | `#2f855a` | Positive states, healthy budgets |
+| `--success-soft` | `#edf7f0` | Success background tint |
+| `--line` | `rgba(15,23,42,0.08)` | Subtle borders |
+| `--line-strong` | `rgba(15,23,42,0.14)` | Emphasized borders |
+
+The warm terracotta accent (`#c06a3a`) is the signature color. It appears in active states, primary buttons, focus rings, and the icon fill for active sidebar items. Use sparingly - it should draw the eye to what matters.
+
+### Typography Scale
+
+- Page titles: 31px, -0.03em tracking
+- Section headings: 18px semibold, -0.01em
+- Body/labels: 14px
+- Compact UI (sidebar, pills, badges): 13px, 0.005em tracking
+- Captions/meta: 12px
+- Micro labels (section headers, status pills): 10-11px uppercase, wide tracking (0.08-0.12em)
+- Monospace (logs, IDs, timestamps): JetBrains Mono, 11-12px
+
+### Spacing & Radius
+
+- Border radius: 6-8px for interactive elements, 10px for cards/panels
+- Sidebar width: 220px fixed
+- Content max-width: 1040px centered
+- Page padding: 40px horizontal, 32px vertical
+- Section spacing: 56px (space-y-14) between major sections
+
+### Animation Principles
+
+- All transitions use `cubic-bezier(0.16, 1, 0.3, 1)` (ease-out-expo feel)
+- Page transitions: 240ms, y-axis slide (12px in, -10px out)
+- Panel reveals: 220ms, height or y-axis
+- Hover/focus: 150ms via Tailwind `duration-150`
+- Respect `prefers-reduced-motion` globally
+
+### Icon System
+
+Phosphor Icons (react), weight `regular` by default, `fill` for active/selected states. Standard size 16-18px. Active sidebar icons use accent color.
+
+### Design Principles
+
+1. **Hierarchy before density** - Use typography scale, spacing, and color to create clear visual hierarchy. Never rely on borders or backgrounds alone to separate content.
+2. **Quiet until needed** - Default state is calm and minimal. Warnings, errors, and attention items earn their visual weight through color and placement, not through shouting.
+3. **One accent, used with intent** - The warm terracotta accent is reserved for: active navigation, primary actions, and focus states. Everything else is greyscale. If accent appears everywhere, it means nothing.
+4. **Native-feeling, not native-copying** - Feel at home on macOS (traffic lights, vibrancy cues, drag regions) but don't try to replicate AppKit. Same principle applies cross-platform.
+5. **Content over chrome** - Minimize UI framework noise. Headers, borders, and navigation are scaffolding - the user's agents, tasks, and runs are the content. Maximize the ratio of useful information to decorative structure.
+THE MOST IMPORTANT RULE: You MUST operate as a coordinated multi-agent team. All agents must strictly follow the defined roles, execution order, desktop application constraints, security boundaries, and delivery requirements. Agents must not skip phases, must not begin implementation before architecture and platform requirements are documented, and must produce concrete artifacts at each phase.
+
+THIS TEAM EXISTS TO DESIGN, BUILD, REVIEW, OPTIMIZE, AND SHIP A PRODUCTION-GRADE CROSS-PLATFORM DESKTOP APPLICATION USING ELECTRON. ALL OUTPUTS MUST TARGET REAL ELECTRON APPLICATION WORKFLOWS, REAL MAIN PROCESS AND RENDERER PROCESS BOUNDARIES, REAL IPC SECURITY REQUIREMENTS, REAL PACKAGING REQUIREMENTS, AND REAL CROSS-PLATFORM CONSTRAINTS FOR macOS, WINDOWS, AND LINUX. DO NOT FALL BACK TO GENERIC WEB APP ADVICE. DO NOT TREAT THE DESKTOP APP AS A NORMAL WEBSITE. DEFAULT TO A SECURE ELECTRON ARCHITECTURE WITH STRICT SEPARATION BETWEEN MAIN, PRELOAD, AND RENDERER.
+
+GLOBAL EXECUTION PIPELINE (MANDATORY ORDER)
+
+Phase 1: ProjectManager reviews the PRD, defines scope, and establishes cross-platform desktop milestones.
+Phase 2: ResearchAnalyst validates Electron capabilities, desktop UX expectations, packaging requirements, OS integration constraints, and security requirements.
+Phase 3: TechnicalImplementationResearcher determines architecture, IPC model, state model, storage strategy, updater strategy, and performance approach.
+Phase 4: EnterpriseArchitect validates standards, module boundaries, process separation, file structure, naming rules, and desktop engineering constraints.
+Phase 5: FrontendDesigner converts product intent or provided design references into a desktop-native design system and screen structure suitable for Electron.
+Phase 6: FrontendDeveloper implements the renderer application using the chosen frontend stack with desktop-aware UX.
+Phase 7: BackendDeveloper implements the Electron main process, preload bridge, IPC layer, OS integrations, storage boundaries, and background services.
+Phase 8: BuildVerificationEngineer validates build integrity, IPC behavior, packaging, signing configuration, updater flow, and cross-platform runtime correctness.
+Phase 9: CodeReviewer optimizes correctness, warnings, performance, memory behavior, startup time, renderer responsiveness, and bundle size.
+Phase 10: SecurityAuditor performs final audit for IPC safety, preload exposure, file system permissions, secrets handling, updater safety, and release hygiene.
+Phase 11: ProjectManager validates final integration completeness, release readiness, and milestone closure.
+
+Agents must never operate outside this pipeline. Implementation must not begin until scope, architecture, process boundaries, platform requirements, and design constraints are documented.
+
+PROJECT OBJECTIVE
+
+The goal is to produce a production-grade cross-platform desktop application using Electron with clear separation between main process, preload layer, and renderer process, strong IPC discipline, secure OS integration, maintainable architecture, stable packaging, and release-ready behavior across macOS, Windows, and Linux. The application must feel like a real desktop product rather than a website placed inside a desktop shell. Window behavior, menus, keyboard shortcuts, file dialogs, notifications, clipboard interactions, drag and drop, background tasks, persistence, and updater behavior must all be designed as desktop concerns.
+
+PROJECT COMPLETION CRITERIA
+
+The project is complete only when the application builds successfully for supported target platforms, type checking passes, linting passes, unit and integration tests for critical flows pass, renderer and main process communication works correctly, preload exposure is minimal and verified, packaging is valid, signing and notarization requirements are documented where relevant, auto-update strategy is defined if required, crashes and obvious runtime exceptions are eliminated, and no critical security or stability issues remain.
+
+SUPPORTED PLATFORM TARGET
+
+The system must explicitly define whether the app supports macOS only, Windows only, Linux only, or all three desktop targets. If the app is truly cross-platform, platform-specific differences in window chrome, file paths, menu behavior, notifications, keyboard modifiers, tray behavior, installer requirements, permissions, startup behavior, and signing or notarization requirements must be documented and handled intentionally. The application must not assume one platform’s conventions apply unchanged to another.
+
+REPOSITORY STRUCTURE
+
+The repository must follow a clear Electron-native structure.
+
+repo
+apps
+desktop
+src
+main
+preload
+renderer
+components
+pages
+hooks
+state
+services
+ipc
+storage
+platform
+utils
+assets
+tests
+unit
+integration
+e2e
+scripts
+build
+docs
+electron-builder.yml
+package.json
+tsconfig.json
+.env.example
+
+If the project is monorepo-based, workspace boundaries must remain explicit and maintainable. If the project is single-package, process boundaries must still remain explicit and not collapse into one mixed folder.
+
+MILESTONE STRUCTURE
+
+The ProjectManager must define milestones using native desktop release stages. At minimum these stages include architecture freeze, interactive prototype, internal alpha, cross-platform validation, signed beta build, release candidate, and production release readiness. Each milestone must specify feature scope, technical dependencies, blockers, packaging expectations, updater expectations, and acceptance criteria.
+
+ELECTRON SECURITY FIRST RULE
+
+Electron security is mandatory and not optional. The application must use contextIsolation enabled by default, nodeIntegration disabled in renderer by default, sandbox enabled where feasible, and a tightly scoped preload bridge. Renderer code must never access Node.js APIs directly unless explicitly allowed through audited preload exposure. Remote code execution risk, arbitrary file access, unsafe shell execution, and unrestricted IPC are forbidden.
+
+ARCHITECTURE DECISION RULE
+
+Architecture must be selected based on application complexity and process separation requirements. The team must evaluate and document why the chosen renderer framework and state strategy are appropriate for the project, including how the main process, preload layer, renderer, shared types, IPC contracts, storage layer, and background jobs interact. Architecture must be decided before full implementation begins. The system must avoid both monolithic god modules and unnecessary fragmentation.
+
+PROCESS BOUNDARY RULE
+
+The main process owns privileged access, OS integration, window lifecycle, menus, native dialogs, updater orchestration, and sensitive operations. The preload layer exposes a minimal, typed, audited bridge. The renderer handles UI, presentation logic, local interaction state, and calls only approved preload APIs. Business-critical privileged operations must never be executed directly in the renderer. Process boundaries must remain explicit, documented, and enforced by code structure.
+
+IPC CONTRACT RULE
+
+All IPC channels must be typed, versioned if needed, explicitly named, and documented. Unstructured string-based ad hoc IPC is forbidden. Every IPC operation must define request shape, response shape, error shape, privilege level, timeout expectations, and validation requirements. IPC handlers must validate inputs on the privileged side before performing any filesystem, network, shell, or OS-level action.
+
+STATE MANAGEMENT RULE
+
+State ownership must be explicit. UI-local state, app-global state, persisted state, async loading state, window state, and background task state must be clearly separated. The renderer must not become a dumping ground for all application logic. If shared state crosses process boundaries, that transfer must be deliberate and typed. The system must document where React Query, Zustand, Redux, Context API, or other state tools are used and why.
+
+STORAGE RULE
+
+Persistence must be chosen deliberately based on the app’s data model and offline behavior. The team must document whether persistence uses local files, SQLite, IndexedDB, key-value storage, or another desktop-safe mechanism. Sensitive data must never be stored insecurely when OS keychain or secure credential storage is available. Migration behavior, corruption handling, backup expectations, and recovery behavior must be documented. Storage locations must follow platform conventions.
+
+NETWORKING RULE
+
+If networking is required, the team must define whether requests originate in the main process or renderer and why. Timeout handling, retry behavior, cancellation, auth storage, offline support, background sync, streaming, and serialization rules must be documented. The app must never assume stable connectivity. Sensitive network requests should prefer the more controlled side of the architecture when security requires it.
+
+DESKTOP UX RULE
+
+All UI must be designed as desktop UI, not as transplanted mobile UI or plain website UI. The design must account for resizable windows, minimum window sizes, keyboard-first workflows, hover states, focus states, menus, context menus, drag and drop, clipboard flows, file system interactions, multi-window behavior if needed, command palette if relevant, and platform-specific modifier keys. Desktop affordances must be explicit and intentional.
+
+DESIGN SYSTEM RULE
+
+The FrontendDesigner must convert product intent or provided references into a desktop-compatible design system and view hierarchy. Typography scale, spacing scale, color tokens, surface hierarchy, focus states, hover states, loading states, empty states, error states, disabled states, and density behavior must be defined. If the application needs light mode and dark mode, that requirement must be specified early and implemented consistently. Icons, font loading, window framing behavior, and panel layouts must be documented.
+
+ACCESSIBILITY RULE
+
+Accessibility is mandatory. The application must support keyboard navigation, focus visibility, sufficient color contrast, readable sizing, reduced motion behavior where applicable, semantic roles where supported by the renderer framework, and accessible labeling for important interactions. Accessibility support must be treated as a product requirement rather than an optional polish pass.
+
+OBSERVABILITY RULE
+
+Diagnostic output must use structured logging with clear source ownership across main, preload, and renderer. Ad hoc console logging in final output is forbidden unless routed through a controlled logging strategy. Logs must not expose secrets, tokens, local private paths unless necessary, or personal user data. Crashes, failed IPC calls, updater issues, packaging issues, and important service failures must be observable without becoming noisy or unsafe.
+
+TESTING RULE
+
+The application must include testing appropriate to its scope. Core logic, IPC contracts, state transitions, storage boundaries, parsing, and critical workflows should have unit or integration tests. Important user flows should have end-to-end coverage where feasible. Cross-process behaviors must be tested deliberately, not assumed. Manual verification steps must be documented where automation is impractical.
+
+PACKAGING AND RELEASE RULE
+
+The system must produce release output suitable for native desktop distribution. Packaging expectations must be defined per platform, including macOS app bundle and signing or notarization expectations, Windows executable or installer expectations, and Linux packaging expectations if applicable. Auto-update strategy, icons, metadata, versioning, release channel separation, environment separation, and debug-versus-release behavior must be documented. Debug-only code must not remain in release output.
+
+PERFORMANCE RULE
+
+The application must feel responsive and desktop-grade. Startup time, idle memory usage, renderer responsiveness, large list performance, background task isolation, bundle size, unnecessary re-renders, preload overhead, IPC latency, and window creation performance must all be reviewed. Heavy CPU work must not block the renderer. Long-running privileged tasks must not freeze the UI. Performance-sensitive paths must be identified early rather than patched late.
+
+PROJECTMANAGER — ELECTRON PRD REVIEWER AND COORDINATOR
+
+The ProjectManager reviews the PRD and defines cross-platform desktop milestones, feature sequencing, dependency order, and delivery checkpoints. This role sets platform support requirements, packaging expectations, updater expectations, release stages, and coordination rules between design, renderer implementation, and main process implementation. The ProjectManager ensures that product scope remains realistic for Electron architecture and that milestone definitions are concrete enough for build execution.
+
+RESEARCHANALYST — ELECTRON ECOSYSTEM AND DESKTOP RESEARCHER
+
+The ResearchAnalyst researches current Electron capabilities, security recommendations, OS integration constraints, packaging requirements, secure storage options, updater options, platform-specific behavior, accessibility realities, and relevant open source implementation references. This role must distinguish between what Electron supports directly, what must be implemented through Node or native modules, and what remains risky or costly. The output must be concise, current, and implementation-relevant.
+
+TECHNICALIMPLEMENTATIONRESEARCHER — ELECTRON DESKTOP ARCHITECTURE AND OPTIMIZATION RESEARCHER
+
+The TechnicalImplementationResearcher studies the most efficient implementation path for the target features. This includes evaluating renderer framework choice, IPC modeling, preload API design, storage options, updater integration, worker usage, file watching, background processing, media handling, caching strategy, multi-window coordination, and memory behavior. The goal is to recommend a maintainable and performant architecture specifically for a desktop Electron application.
+
+FRONTENDDESIGNER — DESKTOP ELECTRON UI AND UX DESIGN REVIEWER
+
+The FrontendDesigner reviews provided design material and adapts it into a desktop-native design system and screen structure suitable for Electron. This role defines layout rules, spacing, typography, focus states, hover states, command surfaces, window-responsive behavior, toolbar behavior, panel layout, and desktop interaction flows. The design output must reflect actual desktop constraints including resizable windows, sidebars, toolbars, tabs if relevant, keyboard-first workflows, context menus, and dense information layouts where appropriate.
+
+ENTERPRISEARCHITECT — ELECTRON CODE STANDARDS GUARDIAN
+
+The EnterpriseArchitect enforces strict engineering rules. Main, preload, and renderer code must remain separated. No god modules are allowed. No direct Node access in renderer is allowed unless explicitly justified and audited. All IPC must be typed and validated. Secrets must never be hardcoded. Shell execution, filesystem access, and external process spawning must be isolated and strictly controlled. Reusable logic must not be duplicated. File naming must be descriptive and consistent. Shared types must be centralized. Public preload surface must be minimal. The architecture must remain secure and maintainable rather than imitating an unbounded full-trust desktop script.
+
+FRONTENDDEVELOPER — ELECTRON RENDERER ENTERPRISE ENGINEER
+
+The FrontendDeveloper implements the renderer application using the chosen frontend stack with strict type safety, maintainable component structure, predictable state management, desktop-aware interaction patterns, and minimal assumptions about privileged access. The renderer must consume only approved preload APIs or safe local browser APIs. The developer must implement loading states, error states, empty states, responsive window behavior, and keyboard-friendly interactions appropriate for desktop usage.
+
+BACKENDDEVELOPER — ELECTRON MAIN PROCESS AND PRELOAD ENGINEER
+
+The BackendDeveloper implements the Electron main process, preload bridge, IPC handlers, privileged integrations, storage access boundaries, menus, dialogs, notifications, background tasks, updater coordination, and platform integrations. This role owns sensitive operations and must validate all inputs before executing privileged actions. The preload layer must expose only minimal typed APIs. The implementation must be production-grade, secure, and aligned with the approved process model.
+
+BUILDVERIFICATIONENGINEER — ELECTRON BUILD, PACKAGE, AND DEPLOYMENT SPECIALIST
+
+The BuildVerificationEngineer validates local builds, packaging configuration, signing expectations, environment separation, preload bundling, IPC wiring, updater flow if applicable, installer integrity, and cross-platform runtime correctness. This role must confirm that production builds behave correctly, source maps and debug settings are handled appropriately, packaged apps launch correctly, and release artifacts are consistent with expectations.
+
+CODEREVIEWER — ELECTRON BUILD OPTIMIZER AND PERFORMANCE TUNER
+
+The CodeReviewer eliminates type errors, lint issues, avoidable bundle bloat, unnecessary renderer re-renders, untyped IPC paths, memory leaks, stale event listeners, preload overexposure, slow startup behavior, and privileged operations running on the wrong side of the architecture. This role reviews both correctness and runtime suitability for Electron desktop execution.
+
+SECURITYAUDITOR — ELECTRON SECURITY AND RELEASE AUDITOR
+
+The SecurityAuditor performs the final security and release review. Context isolation, sandbox policy, node integration policy, preload exposure, IPC validation, filesystem safety, secure credential storage, updater trust model, remote content policy, CSP strategy, shell execution boundaries, debug feature removal, and packaging hygiene must all be reviewed. The final audit must clearly state whether the application is safe and appropriate for internal alpha, public beta, or production release.
+
+IMPLEMENTATION CONSTRAINTS
+
+Use Electron as the desktop runtime. Maintain strict separation between main, preload, and renderer. Disable nodeIntegration in renderer by default. Enable contextIsolation by default. Use a minimal preload bridge. Validate all IPC inputs. Do not expose arbitrary filesystem, shell, or process APIs to renderer code. Do not hardcode secrets. Do not treat the desktop app as a normal website. Do not start implementation before milestone definition, architecture decision, process boundary review, platform requirement review, and design constraints are complete.
+
+Carefully review the full `PRD.md` and then inspect every single line of the current Electron cross-platform desktop application codebase, including main process, renderer process, preload scripts, IPC architecture, window lifecycle, view structure, routing, UI flow, interaction logic, state management, local persistence, file system access, settings model, update flow, packaging configuration, platform integrations, security model, performance behavior, and all existing screens, panels, dialogs, and workflows. The current application is not usable as a real product: it lacks meaningful interaction, lacks coherent UX flow, lacks clear information hierarchy, lacks robust state handling, lacks polished desktop behavior, lacks complete feature implementation, lacks proper security boundaries, and lacks the depth required for a finished cross-platform Electron application. Treat the current build as an unusable prototype and fully redesign it into a complete, production-ready, polished desktop product.
+
+Your task is to fully rebuild the application into a feature-complete, maintainable, performant, and production-ready cross-platform desktop experience. Do not do superficial edits. Do not only patch isolated bugs. Do not leave placeholder windows, placeholder views, placeholder copy, placeholder workflows, placeholder IPC hooks, incomplete screens, incomplete platform integrations, insecure bridges, mock logic, or “TODO” implementations. Redo the whole application in depth. This includes but is not limited to: full product flow, onboarding, window structure, multi-panel layout if relevant, navigation, keyboard and mouse interactions, drag-and-drop if relevant, empty states, loading states, error states, visual hierarchy, interaction feedback, text content, settings flow, persistence, async/background task coordination, IPC boundaries, file workflows, command palette if relevant, system integrations, update behavior, and overall product cohesion.
+
+Build the app as if it must stand on its own as a real commercial desktop product, not a demo. Every screen must have purpose. Every control must have a clear function. Every interaction must produce visible and coherent feedback. Every major section must have readable information architecture, UX integrity, visual hierarchy, and product meaning. Add proper onboarding so a first-time user can understand what to do. Add product structure so the app has a reason to be used continuously. Add all missing interaction logic. Add polished UI presentation. Add complete user-facing text wherever necessary. Add proper settings, logs, history, file/workspace flow, shortcuts, menus, dialogs, and desktop-native behaviors expected from a serious Electron application.
+
+You must work systematically and deeply, not lazily. First, audit the entire PRD and the full codebase. Identify all broken, missing, shallow, placeholder, insecure, or incoherent systems. Then redesign the application architecture where needed so the final result is maintainable and expandable. Then implement the full app end to end. Rewrite systems if the current ones are fundamentally bad. Replace weak screens if needed. Replace weak state flow if needed. Replace weak IPC design if needed. Rewrite copy, flows, and interaction logic if needed. Improve visual design, event handling, async coordination, security boundaries, state transitions, platform adaptation, and UX details so the result feels intentional and complete.
+
+The rebuilt application must be truly designed for Electron and desktop-quality behavior, not just a web page wrapped in a shell. Respect the Electron architecture properly. Build a clean separation between main process, renderer process, and preload layer. Use secure IPC patterns. Minimize attack surface. Use context isolation, disable unsafe defaults, expose only explicit preload APIs, and avoid insecure renderer access to Node capabilities. Handle native menus, window controls, file dialogs, notifications, clipboard access, deep links, protocol handlers, and OS integrations properly where relevant. The final product must feel like a serious desktop application on macOS, Windows, and Linux, not a browser tab pretending to be native.
+
+Prefer a production-grade Electron architecture and implementation style: strong module boundaries, explicit state ownership, clear separation between UI, domain logic, desktop integration, and persistence, predictable async execution, structured IPC contracts, robust error propagation, structured logging, testable units, maintainable packaging, and release-ready update strategy. If the current stack is weak or inconsistent, replace it with a maintainable Electron-native architecture.
+
+If relevant, support:
+- Multi-window or multi-panel workflows.
+- Workspace/project-based usage model.
+- Local-first persistence where appropriate.
+- File system integration, drag-and-drop, import/export, and artifact management.
+- Keyboard-first desktop workflows and command palette behavior.
+- Run history, logs, diagnostics, and error surfacing.
+- Auto-update flow where appropriate.
+- Crash handling, recovery, and safe state restoration.
+- Cross-platform packaging and runtime stability.
+- Clear security hardening across main, preload, and renderer boundaries.
+
+Deliverables must include:
+1. A full design and engineering audit of the current PRD and codebase, listing all major problems and why they make the application incomplete, insecure, or unusable.
+2. A complete redesign plan aligned with the PRD, including product flow, screen and window structure, navigation model, interaction model, IPC model, state model, persistence model, platform behavior, security model, and feature structure.
+3. A clear Electron architecture covering main process responsibilities, renderer responsibilities, preload API surface, IPC contracts, permissions, and security boundaries.
+4. Full implementation of all missing or broken systems in code.
+5. Fully functional screens, dialogs, panels, and workflows with complete interactions, guidance, and cross-platform desktop behavior.
+6. Complete user-facing copy and content where required, not placeholders.
+7. Full onboarding and product flow implementation from first launch to continued daily use.
+8. Proper animation and transition polish where technically appropriate for a desktop app.
+9. Application UX polish equivalent to game feel: responsiveness, feedback, clarity, smooth transitions, keyboard usability, pointer precision, and operational confidence.
+10. Removal of dead code, broken systems, placeholder logic, insecure patterns, and unused structures where appropriate.
+11. Packaging, updater, and runtime readiness for supported desktop platforms.
+12. A final fully usable Electron cross-platform desktop application, not a partial refactor.
+
+Rules:
+- Do not be lazy.
+- Do not summarize only.
+- Do not stop at analysis.
+- Do not leave placeholder text such as “coming soon”, “TODO”, “insert copy here”, mock screens, fake workflows, or dummy interactions.
+- Do not preserve bad legacy code just for convenience.
+- Do not make minimal edits when a system needs to be rebuilt.
+- Do not ask for unnecessary confirmation if the PRD and codebase already contain enough direction.
+- Make strong implementation decisions where needed and document them clearly.
+- Maintain internal consistency across product logic, UI, state, IPC behavior, persistence, async behavior, security boundaries, and platform integration.
+- Keep the visual and interaction design cohesive with a polished, premium desktop product identity.
+- Respect Electron constraints and strengths, but do not use them as an excuse for weak UX, poor security, or incomplete functionality.
+- Do not rush or shortcut the work. You can continuously work for a very long time if needed, including days or even non-stop work across weeks.
+- You have sufficient time and effectively unlimited token budget, so depth, completeness, and quality are more important than speed.
+
+Execution order:
+Phase 1: Read and understand the entire `PRD.md`.
+Phase 2: Review the entire codebase line by line and identify all structural, UX, engineering, IPC, security, platform, and packaging deficiencies.
+Phase 3: Produce a concrete rebuild plan.
+Phase 4: Redesign the desktop architecture across main process, renderer, preload, persistence, and platform integration.
+Phase 5: Implement the rebuilt app system by system.
+Phase 6: Connect all features into a complete and coherent Electron-based cross-platform desktop experience.
+Phase 7: Polish UX, state flow, async behavior, IPC contracts, security, platform behavior, keyboard workflows, animation, and packaging.
+Phase 8: Final verification: the application must be launchable, understandable, navigable, responsive, useful, stable, secure, and complete across supported desktop platforms.
+
+Assume the goal is not “improve a prototype” but “finish the app for real.” Act like a principal Electron engineer, desktop architect, security engineer, product designer, UX designer, build/release engineer, and technical director combined. Produce real implementation, real workflows, and a complete result.
\ No newline at end of file
diff --git a/README.md b/README.md
new file mode 100644
index 00000000..9428f19e
--- /dev/null
+++ b/README.md
@@ -0,0 +1,47 @@
+# AgentCompany
+
+Cross-platform Electron desktop control plane for local-first AI agent companies.
+
+AgentCompany is a standalone desktop application for managing multiple AI coding agents (Codex, Claude Code, Gemini CLI, OpenCode, Kimi Code) as an organization with goals, tasks, approvals, budgets, and audit trails.
+
+## Quick Start
+
+```sh
+pnpm install
+pnpm dev
+```
+
+## Verification
+
+```sh
+pnpm typecheck
+pnpm lint
+pnpm test:unit
+pnpm test:integration
+pnpm build
+```
+
+## Packaging
+
+```sh
+pnpm build # Compile + package (DMG/NSIS/AppImage)
+pnpm build:dir # Compile + unpackaged directory
+```
+
+- Supported targets: macOS, Windows, Linux
+- Packaging uses `electron-builder`
+- Local builds use ad-hoc signing (`CSC_IDENTITY_AUTO_DISCOVERY=false`)
+- Defaults to `--publish never`; override with `AGENTCOMPANY_ELECTRON_PUBLISH` env var
+
+## Architecture
+
+```
+src/
+ main/ # Electron main process, IPC, orchestration, database
+ preload/ # Typed bridge (contextIsolation)
+ renderer/ # React UI
+ shared/ # Contracts, types shared across processes
+packages/
+ adapter-utils/ # Shared adapter utilities
+ adapter-*/ # Per-connector adapter packages
+```
diff --git a/assets/icon.icns b/assets/icon.icns
new file mode 100644
index 00000000..4e90364c
Binary files /dev/null and b/assets/icon.icns differ
diff --git a/assets/icon.ico b/assets/icon.ico
new file mode 100644
index 00000000..51fce758
Binary files /dev/null and b/assets/icon.ico differ
diff --git a/assets/icon.png b/assets/icon.png
new file mode 100644
index 00000000..9a5ed061
Binary files /dev/null and b/assets/icon.png differ
diff --git a/assets/icon.svg b/assets/icon.svg
new file mode 100644
index 00000000..36d4964d
--- /dev/null
+++ b/assets/icon.svg
@@ -0,0 +1,21 @@
+
diff --git a/docs/01-project-manager-scope.md b/docs/01-project-manager-scope.md
new file mode 100644
index 00000000..39694cdf
--- /dev/null
+++ b/docs/01-project-manager-scope.md
@@ -0,0 +1,205 @@
+# Phase 1: ProjectManager Scope And Milestones
+
+## Product Frame
+
+- Product working name: `AgentCompany`
+- Product type: cross-platform Electron desktop application
+- Platform target: macOS, Windows, Linux
+- Primary mode: local-first single-operator control plane
+- Product goal: run a multi-agent company from one desktop application with explicit control over connectors, workspaces, tasks, runs, approvals, budgets, logs, and recovery
+
+## Scope Source
+
+- Existing Paperclip concept from `doc/GOAL.md`, `doc/PRODUCT.md`, `doc/SPEC-implementation.md`
+- Rebuild constraints and product direction from `/Users/zacharyzhang/Documents/Github/paperclip/PRD.md`
+
+## Supported MVP Domains
+
+- Local profile with backup and restore
+- Multi-company local data model
+- Connector registry with capability matrix
+- Agent registry and org tree
+- Goals, projects, tasks, lineage
+- Run orchestration with session persistence and live console
+- Approval queue and governance actions
+- Cost tracking and budget hard-stop behavior
+- Activity timeline and run diagnostics
+- Workspace and repository management
+- Secret management with OS-backed encryption where available
+- Packaging, signing configuration, updater wiring, and crash-safe recovery hooks
+
+## Explicit Platform Decision
+
+AgentCompany targets all three desktop platforms in the first implementation.
+
+Platform-specific constraints that must be handled intentionally:
+
+- macOS:
+ - standard traffic-light window controls
+ - `Cmd` modifiers in menus and shortcuts
+ - notification permission behavior
+ - notarization and Developer ID signing requirements
+ - `safeStorage` may block while Keychain access is resolved
+- Windows:
+ - NSIS installer target
+ - `Ctrl` modifiers in menus and shortcuts
+ - AppUserModelID and toast notification expectations
+ - code signing certificate requirement for trusted distribution
+- Linux:
+ - AppImage target with optional deb/rpm later
+ - tray behavior differs by desktop environment
+ - `safeStorage` backend may degrade to `basic_text`, so fallback vault behavior must stay explicit
+
+## Delivery Milestones
+
+### 1. Architecture Freeze
+
+Feature scope:
+
+- final process model
+- profile/storage layout
+- IPC contract surface
+- connector capability model
+- initial screen map
+
+Dependencies:
+
+- PRD audit
+- Electron security research
+- platform packaging research
+
+Acceptance criteria:
+
+- architecture docs complete
+- privileged boundaries defined
+- no renderer-to-Node direct access
+
+### 2. Interactive Prototype
+
+Feature scope:
+
+- shell window
+- top nav + sidebar + utility drawer
+- onboarding flow
+- fake local data rendered from real repositories/services
+
+Dependencies:
+
+- design system
+- typed preload bridge
+- renderer route skeleton
+
+Acceptance criteria:
+
+- navigable desktop shell
+- keyboard navigation baseline
+- console drawer and inspector patterns established
+
+### 3. Internal Alpha
+
+Feature scope:
+
+- local SQLite profile
+- connectors registry and environment checks
+- agents/tasks/approvals/workspaces CRUD
+- utility-process orchestrator
+- real run launch for supported local connectors
+
+Dependencies:
+
+- repository layer
+- connector host
+- activity logging
+
+Acceptance criteria:
+
+- launch first task run from onboarding
+- view live logs
+- persist app state across restart
+
+### 4. Cross-Platform Validation
+
+Feature scope:
+
+- window/menu differences
+- path handling
+- notifications
+- backup/restore
+- crash recovery path
+
+Dependencies:
+
+- packaged test builds
+- platform QA checklist
+
+Acceptance criteria:
+
+- app boots and navigates on macOS, Windows, Linux
+- core workflows verified on each target
+
+### 5. Signed Beta Build
+
+Feature scope:
+
+- electron-builder config
+- signing env handling
+- updater channel wiring
+- production logging paths
+
+Dependencies:
+
+- build pipeline
+- signing assets
+
+Acceptance criteria:
+
+- signed distributables generated
+- updater checks optional and disableable
+- release metadata generated
+
+### 6. Release Candidate
+
+Feature scope:
+
+- performance pass
+- memory/resource leak pass
+- e2e coverage for critical flows
+- security audit fixes
+
+Dependencies:
+
+- alpha feedback
+- perf instrumentation
+
+Acceptance criteria:
+
+- no known critical security issue
+- no crash in scripted happy path flows
+- startup and live console remain responsive under load
+
+### 7. Production Release Readiness
+
+Feature scope:
+
+- release checklist
+- support docs
+- backup guidance
+- known limitations register
+
+Dependencies:
+
+- verification results
+- signing and packaging validation
+
+Acceptance criteria:
+
+- typecheck/build/tests pass or deviations are explicitly recorded
+- security and packaging docs complete
+- final manual QA checklist complete
+
+## Feature Sequencing Rules
+
+- Connector execution begins only after IPC and orchestration boundaries are documented.
+- Renderer implementation begins only after screen structure and state ownership are defined.
+- Packaging config begins early, but signing and updater activation stay behind environment gating.
+- Kimi support is tracked explicitly. If its runtime contract remains lower capability than other first-class connectors, the UI must declare the downgrade rather than hiding it.
diff --git a/docs/02-current-paperclip-audit.md b/docs/02-current-paperclip-audit.md
new file mode 100644
index 00000000..f6b28234
--- /dev/null
+++ b/docs/02-current-paperclip-audit.md
@@ -0,0 +1,162 @@
+# Phase 1: Current Paperclip Audit
+
+## Audit Boundary
+
+This audit compares the current Paperclip repository against the target state defined in `PRD.md`: a secure Electron desktop application with strict `main` / `preload` / `renderer` separation, local-first orchestration, packaging, and OS-integrated workflows.
+
+## Severity 0: Blocking Architectural Mismatch
+
+### 1. No Electron process model exists
+
+- Current repo contains no `BrowserWindow`, `preload`, `contextBridge`, `ipcMain`, `ipcRenderer`, `utilityProcess`, or packaging configuration.
+- Evidence:
+ - root search for Electron APIs returns no application implementation
+ - [server/src/app.ts](/Users/zacharyzhang/Documents/Github/paperclip/server/src/app.ts)
+ - [ui/src/App.tsx](/Users/zacharyzhang/Documents/Github/paperclip/ui/src/App.tsx)
+
+Impact:
+
+- There is no privileged boundary for filesystem, keychain, window lifecycle, native dialogs, menus, notifications, updater, or desktop protocol handling.
+- The current product cannot be hardened into a desktop app by shell-wrapping the existing UI.
+
+### 2. Orchestration is server-centric, not desktop-local
+
+- Heartbeat execution, run tracking, workspace realization, and activity propagation live in the server process.
+- Evidence:
+ - [server/src/services/heartbeat.ts](/Users/zacharyzhang/Documents/Github/paperclip/server/src/services/heartbeat.ts)
+ - [server/src/services/workspace-runtime.ts](/Users/zacharyzhang/Documents/Github/paperclip/server/src/services/workspace-runtime.ts)
+
+Impact:
+
+- The current implementation assumes a long-lived backend service instead of a desktop-owned local orchestration core.
+- Crash semantics, app restart recovery, and foreground/background coordination are not modeled as desktop concerns.
+
+### 3. The product shell is a routed web board, not a desktop console
+
+- The top-level UI is route-driven, page-centric, and optimized for browser navigation rather than split-pane desktop operations.
+- Evidence:
+ - [ui/src/App.tsx](/Users/zacharyzhang/Documents/Github/paperclip/ui/src/App.tsx)
+ - [ui/src/components/Layout.tsx](/Users/zacharyzhang/Documents/Github/paperclip/ui/src/components/Layout.tsx)
+
+Impact:
+
+- No desktop-native command surfaces for file dialogs, tray, menu actions, run console docking, workspace reveal, or keyboard-first operations.
+- Core runtime objects such as connector health, workspace locks, session continuity, and log streams are not first-order interaction primitives.
+
+## Severity 1: Major Product And UX Gaps
+
+### 4. Onboarding is web-form oriented and does not establish a desktop local profile
+
+- Existing onboarding creates company, CEO, and task records through API calls, but it does not create a local profile boundary, filesystem roots, workspace permissions, or connector health setup.
+- Evidence:
+ - [ui/src/components/OnboardingWizard.tsx](/Users/zacharyzhang/Documents/Github/paperclip/ui/src/components/OnboardingWizard.tsx)
+
+Impact:
+
+- First launch does not establish the desktop objects required by the PRD: local profile, workspace selection, connector detection, secret storage, and first-run orchestration.
+
+### 5. Connector differences are hidden inside adapter packages instead of surfaced as product-level capability states
+
+- Adapters exist, but the UI treats them mainly as form configuration.
+- Evidence:
+ - [server/src/adapters/registry.ts](/Users/zacharyzhang/Documents/Github/paperclip/server/src/adapters/registry.ts)
+ - [ui/src/adapters/index.ts](/Users/zacharyzhang/Documents/Github/paperclip/ui/src/adapters/index.ts)
+
+Impact:
+
+- Users cannot reason about installation status, auth status, session resume support, structured transcript support, graceful cancel support, or unattributed cost behavior at the product level.
+
+### 6. Workspace and repo context are present in backend logic but weak in the product hierarchy
+
+- Workspace realization and worktree logic already exist, but they are not promoted to a central desktop experience.
+- Evidence:
+ - [server/src/services/workspace-runtime.ts](/Users/zacharyzhang/Documents/Github/paperclip/server/src/services/workspace-runtime.ts)
+ - [doc/DEVELOPING.md](/Users/zacharyzhang/Documents/Github/paperclip/doc/DEVELOPING.md)
+
+Impact:
+
+- The codebase contains useful execution semantics, but the current UI still behaves like a CRUD admin console with runtime details buried behind secondary screens.
+
+### 7. Run console and diagnostics are not treated as a persistent operational surface
+
+- Logs and transcript UX exist, but not as a docked desktop utility layer with search, filtering, and background status awareness.
+- Evidence:
+ - [ui/src/components/transcript/RunTranscriptView.tsx](/Users/zacharyzhang/Documents/Github/paperclip/ui/src/components/transcript/RunTranscriptView.tsx)
+ - [ui/src/pages/RunTranscriptUxLab.tsx](/Users/zacharyzhang/Documents/Github/paperclip/ui/src/pages/RunTranscriptUxLab.tsx)
+
+Impact:
+
+- Long-running desktop workflows need a utility drawer, live fan-out events, failure escalation, and state restoration, which the current web UX does not provide.
+
+## Severity 2: Security And Desktop-Readiness Gaps
+
+### 8. No preload boundary means there is no audited API surface for privileged actions
+
+Impact:
+
+- Desktop actions such as open folder, reveal artifact, backup profile, launch connector, store secret, or trigger updater would currently have no typed, validated boundary.
+
+### 9. Secret handling is designed for server deployment, not OS keychain-first desktop storage
+
+- Current repo includes secret versioning and local encrypted storage semantics.
+- Evidence:
+ - [server/src/services/secrets.ts](/Users/zacharyzhang/Documents/Github/paperclip/server/src/services/secrets.ts)
+ - [doc/DATABASE.md](/Users/zacharyzhang/Documents/Github/paperclip/doc/DATABASE.md)
+
+Impact:
+
+- The PRD requires OS-backed secure storage first. The current implementation does not model Electron `safeStorage`, keychain backend selection, or desktop fallback behavior.
+
+### 10. Packaging, signing, and updater flows do not exist
+
+Impact:
+
+- There is no release artifact model for DMG/NSIS/AppImage, no signing config, no update metadata flow, and no environment gates for release versus dev behavior.
+
+### 11. IPC sender validation, CSP, and custom protocol concerns are absent because there is no desktop surface yet
+
+Impact:
+
+- These are not bugs in the current web app, but they are missing mandatory controls for the target architecture.
+
+## Severity 3: Maintainability Risks When Porting Directly
+
+### 12. Existing routes and page layout would pull too much orchestration detail into the renderer
+
+- The current UI is page-heavy and query-heavy.
+- Directly transplanting it into an Electron renderer would encourage business and privileged logic to leak upward.
+
+### 13. Current shared contracts are REST-oriented
+
+- Existing shared types target HTTP API payloads and server validation.
+- Evidence:
+ - [packages/shared/src/api.ts](/Users/zacharyzhang/Documents/Github/paperclip/packages/shared/src/api.ts)
+ - [packages/shared/src/types](/Users/zacharyzhang/Documents/Github/paperclip/packages/shared/src/types)
+
+Impact:
+
+- Desktop IPC contracts need operation-specific schemas, privilege labels, and request/response/error shapes rather than generic REST reuse.
+
+### 14. Current database layer is PostgreSQL-first
+
+- Evidence:
+ - [packages/db/src/schema](/Users/zacharyzhang/Documents/Github/paperclip/packages/db/src/schema)
+ - [doc/DATABASE.md](/Users/zacharyzhang/Documents/Github/paperclip/doc/DATABASE.md)
+
+Impact:
+
+- The desktop app needs an embedded local database with explicit migration and recovery semantics. The current schema is a strong domain reference, but not a direct persistence drop-in.
+
+## Valuable Assets To Reuse
+
+- Company-scoped domain language
+- Agent org tree semantics
+- Goal / project / issue lineage rules
+- Approval lifecycle semantics
+- Budget and cost event concepts
+- Existing local connector adapter patterns for Codex, Claude, Gemini, OpenCode, Cursor, and generic process/http modes
+- Workspace and runtime service orchestration ideas
+
+## Rewrite Decision
+
+AgentCompany should reuse domain concepts and selected adapter/runtime patterns, but it should not inherit the current app shell, server-centric topology, or browser-admin navigation model.
diff --git a/docs/03-research-analyst-findings.md b/docs/03-research-analyst-findings.md
new file mode 100644
index 00000000..bd29ad0c
--- /dev/null
+++ b/docs/03-research-analyst-findings.md
@@ -0,0 +1,99 @@
+# Phase 2: ResearchAnalyst Findings
+
+## Sources
+
+- Electron security checklist: https://www.electronjs.org/docs/latest/tutorial/security
+- Electron safeStorage API: https://www.electronjs.org/docs/latest/api/safe-storage
+- Electron utilityProcess API: https://www.electronjs.org/docs/latest/api/utility-process
+- electron-builder auto-update: https://www.electron.build/auto-update
+- electron-builder code signing: https://www.electron.build/code-signing
+- Electron releases schedule: https://releases.electronjs.org/schedule
+- Electron releases index: https://releases.electronjs.org/release
+- Kimi Code official product/docs entry:
+ - https://www.kimi.com/code
+ - https://www.kimi.com/code/docs/en/
+
+## Electron Security Requirements
+
+From current Electron guidance, AgentCompany must treat desktop privilege as a first-order security boundary:
+
+- load only local packaged content in the main renderer
+- keep `nodeIntegration` disabled
+- keep `contextIsolation` enabled
+- keep renderer sandboxing enabled where feasible
+- expose a minimal preload API through `contextBridge`
+- validate IPC sender and payloads
+- restrict navigation and new window creation
+- avoid `file://` in production and prefer a custom protocol
+- define a restrictive CSP
+- never expose shell or filesystem primitives wholesale to renderer code
+
+## Runtime Version Decision
+
+- Initial architecture research targeted Electron `41.0.0`.
+- Build verification on March 12, 2026 found `better-sqlite3@12.6.2` failing native rebuild against Electron `41.0.0` / Node `24.14.0`.
+- The implementation baseline is therefore pinned to Electron `39.8.0` for now.
+
+Why this downgrade is deliberate:
+
+- Electron `39.8.0` is still a stable release line as of March 12, 2026.
+- It preserves the existing SQLite storage implementation without forcing a same-phase storage rewrite.
+- The downgrade is narrower in scope than replacing persistence with a different driver while the product shell, IPC, and orchestration layers are still being completed.
+
+Upgrade condition:
+
+- Revisit Electron `41.x` after the SQLite layer is migrated to a compatible runtime path or the upstream native module supports the newer V8 ABI cleanly.
+
+## Secret Storage Findings
+
+- `safeStorage` is main-process only and uses OS-backed cryptography semantics.
+- macOS: keychain-backed, app-specific protection
+- Windows: DPAPI-backed, user-scope protection
+- Linux: backend varies; it can degrade to `basic_text`
+
+Product implication:
+
+- AgentCompany should use `safeStorage` when encryption is available.
+- On Linux, the app must surface the selected backend and explicitly fall back to an app-local encrypted vault when the selected backend is `basic_text` or unavailable.
+
+## Background Processing Findings
+
+- `utilityProcess.fork()` provides a Chromium-managed child process with Node enabled and message ports available.
+- It is appropriate for orchestration work that should not block the renderer and should stay separate from window lifecycle concerns.
+
+Product implication:
+
+- Use a utility process for the orchestration core, run queue, workspace locks, and connector process supervision.
+- Keep UI projection in renderer, privileged OS coordination in main, and long-running execution in the utility process.
+
+## Packaging And Updater Findings
+
+- electron-builder supports cross-platform packaging with:
+ - macOS: `dmg` plus `zip`
+ - Windows: `nsis`
+ - Linux: `AppImage` and optional deb/rpm variants
+- Auto-update via `electron-updater` relies on generated metadata files such as `latest.yml`.
+- macOS auto-update requires a signed app.
+- Windows signing is also supported and should be treated as a release requirement.
+
+Product implication:
+
+- Package targets should default to DMG/ZIP, NSIS, and AppImage.
+- Update checks must be opt-in/disableable by user setting, as required by the PRD.
+- Signing configuration should be environment-driven and absent values must not block local development.
+
+## Desktop UX Research Conclusions
+
+- Desktop-first operators need split-pane information density, not a marketing-site layout.
+- Keyboard navigation, command surfaces, and context-preserving utility drawers matter more than route purity.
+- File reveal, open folder, drag/drop, and copy path are standard desktop affordances and should be first-class actions.
+
+## Connector Research Conclusions
+
+- The current Paperclip repo already contains strong local connector patterns for Codex, Claude Code, Gemini CLI, and OpenCode.
+- Kimi Code is a real official CLI offering, but its desktop integration contract requires explicit treatment instead of assuming parity with the existing adapters.
+
+Implementation decision:
+
+- Reuse the established adapter contract ideas from current Paperclip for supported local connectors.
+- Represent advanced capability differences explicitly in the connector registry and task/run UX.
diff --git a/docs/04-technical-implementation-research.md b/docs/04-technical-implementation-research.md
new file mode 100644
index 00000000..a55b4098
--- /dev/null
+++ b/docs/04-technical-implementation-research.md
@@ -0,0 +1,128 @@
+# Phase 3: TechnicalImplementationResearcher Decisions
+
+## Architecture Choice
+
+- Runtime: Electron `39.8.0`
+- Renderer: React + Vite + TypeScript
+- UI motion: Framer Motion, used selectively for layout transitions, state feedback, and utility-drawer choreography
+- Data: SQLite with WAL mode and a single-writer orchestration queue
+- Orchestration: Electron utility process
+- Packaging: electron-builder
+- Updates: `electron-updater`, gated by app settings and environment
+
+## Why This Stack
+
+- Electron is required by the project constraints and matches the need for local CLI/runtime orchestration.
+- React is already aligned with repo knowledge and keeps renderer iteration fast.
+- SQLite with WAL provides embedded local durability and low setup overhead, matching the PRD requirement to start without external database installation.
+- A utility process avoids freezing the renderer during process supervision, lock management, or log ingestion.
+
+Version note:
+
+- Electron `41.0.0` was evaluated first, but the shipping baseline moved to `39.8.0` because the current SQLite native dependency did not rebuild cleanly on the newer runtime during packaging verification.
+
+## State Ownership
+
+### Renderer-only state
+
+- split-pane layout and inspector visibility
+- filter/search state
+- command palette visibility
+- form drafts
+- optimistic mutation feedback
+
+### Main-process privileged state
+
+- windows
+- menus
+- file dialogs
+- notifications
+- backup/import/export paths
+- updater lifecycle
+- safeStorage encryption/decryption
+
+### Utility-process orchestration state
+
+- connector child process registry
+- run queue
+- workspace write locks
+- per-agent concurrency locks
+- session persistence and resume eligibility
+- unfinished run reconciliation
+
+### Persisted local state
+
+- companies
+- connectors and connector config documents
+- workspaces
+- agents
+- goals/projects/tasks
+- approvals and comments
+- runs, run events, cost events
+- activity log
+- app settings and window state
+
+## IPC Model
+
+IPC is split into three layers:
+
+1. Renderer to preload:
+ - typed methods only
+ - no raw channel strings in UI components
+2. Preload to main:
+ - schema-validated request/response handlers
+ - sender verified in main
+3. Main to utility process:
+ - internal command bus over message ports
+ - used for orchestration, not for UI privilege elevation
+
+## Storage Strategy
+
+- Database file: `profile.sqlite` under app profile data directory
+- WAL enabled
+- Attachments/logs/artifacts stored as files, indexed in SQLite
+- Secrets stored via `safeStorage` when available; otherwise fallback encrypted vault plus explicit risk state on Linux
+- Backups stored as timestamped archives under `backups/`
+
+## Performance Strategy
+
+- Renderer subscribes to normalized event streams instead of raw connector protocol noise
+- Utility process owns long-running child processes
+- Log viewer uses chunked pagination and windowed rendering
+- Expensive derived summaries are computed in main/utility and sent as projections
+
+## Connector Strategy
+
+Connector contract layers:
+
+- required:
+ - detect installation
+ - health/auth check
+ - execute
+ - normalize stdout/stderr/events
+ - declare capability matrix
+- optional:
+ - session resume
+ - graceful cancel
+ - model discovery
+ - structured transcript
+ - cost attribution
+
+## Updater Strategy
+
+- default channel: disabled unless configured
+- manual update check available from app menu and settings
+- before install:
+ - write backup manifest
+ - flush db/log handles
+- if signature validation fails:
+ - reject install
+ - record audit event
+
+## Failure Model
+
+- app restart scans unfinished runs
+- stale running records become `interrupted`
+- retryable runs expose resume/retry actions in UI
+- workspace lock conflicts enqueue runs as `queued`
+- connector health failures block new run dispatch
diff --git a/docs/05-enterprise-architecture.md b/docs/05-enterprise-architecture.md
new file mode 100644
index 00000000..f78841dd
--- /dev/null
+++ b/docs/05-enterprise-architecture.md
@@ -0,0 +1,113 @@
+# Phase 4: EnterpriseArchitect Standards
+
+## Top-Level Structure
+
+```text
+AgentCompany/
+ assets/
+ build/
+ docs/
+ scripts/
+ src/
+ main/
+ preload/
+ renderer/
+ shared/
+ tests/
+ unit/
+ integration/
+ e2e/
+ electron-builder.yml
+ package.json
+ tsconfig.json
+ .env.example
+```
+
+## Process Boundaries
+
+### Main process owns
+
+- window lifecycle
+- app protocol registration
+- IPC gateway
+- menu construction
+- native dialogs
+- notifications
+- updater
+- backup/restore coordination
+- safeStorage and vault bridge
+
+### Preload owns
+
+- narrow typed API
+- event subscription bridge
+- no business logic
+- no dynamic API exposure
+
+### Renderer owns
+
+- UI composition
+- read-only projections
+- local interaction state
+- invoking approved preload methods
+
+### Utility process owns
+
+- run execution
+- connector process supervision
+- workspace and agent locking
+- timeout handling
+- normalized event emission
+
+## Naming Rules
+
+- Use descriptive file names by role: `connector-service.ts`, `run-controller.ts`, `profile-repository.ts`
+- Shared schemas live under `src/shared`
+- No renderer component may import from `src/main`
+- No preload module may import from `src/renderer`
+
+## IPC Rules
+
+- All channels are constants in `src/shared/contracts/ipc.ts`
+- Every handler validates input with Zod before executing
+- Response shape is always `{ ok, data, error }`
+- Errors use explicit codes, never arbitrary thrown text at the renderer boundary
+
+## Security Rules
+
+- `contextIsolation: true`
+- `sandbox: true` for renderer window
+- `nodeIntegration: false`
+- navigation locked to `app://` content
+- `window.open` denied unless explicitly whitelisted
+- shell execution restricted to orchestration/connector host
+- connector env injection uses allowlists, never raw `process.env`
+
+## Resource Lifetime Rules
+
+Following the memory-safety constraints for long-lived desktop processes:
+
+- every event subscription returns a disposer
+- every spawned child process is registered and terminated on app shutdown
+- timers are stored centrally and cleared on teardown
+- database handles are singleton-owned and closed during quit/update install
+- utility-process channels are recreated deterministically after crash or restart
+
+## Module Boundaries
+
+- `src/shared`: pure types, schemas, ipc contracts, constants
+- `src/main/platform`: OS integration, menu, notifications, paths
+- `src/main/storage`: SQLite, migrations, repositories
+- `src/main/services`: profile, connectors, backups, updater, IPC composition
+- `src/main/orchestrator`: utility-process bootstrap and bridge
+- `src/renderer/pages`: route-level views
+- `src/renderer/components`: reusable UI primitives and panels
+- `src/renderer/state`: UI store, query clients, preferences
+
+## Non-Negotiable Constraints
+
+- No ad hoc IPC from components
+- No direct filesystem or shell access in renderer
+- No secrets in renderer state
+- No mixed god service containing windows, db, and orchestration together
+- No placeholder routes or dead menu entries
diff --git a/docs/06-frontend-design-system.md b/docs/06-frontend-design-system.md
new file mode 100644
index 00000000..a06e5eae
--- /dev/null
+++ b/docs/06-frontend-design-system.md
@@ -0,0 +1,121 @@
+# Frontend Design System
+
+## Product Tone
+
+- Audience: technical operators running multiple AI agents simultaneously
+- Interaction style: dense, precise, keyboard-first
+- Motion style: restrained, purposeful, confidence-building
+- Visual identity: warm, approachable workspace — Linear meets Raycast, not a neon cyber UI
+
+## Typography
+
+- Body/UI family: system stack (`-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif`)
+- Monospace family: JetBrains Mono Variable (`font-family: "JetBrains Mono Variable", monospace`)
+- Scale:
+ - Page titles: 31px, -0.03em tracking
+ - Section headings: 18px semibold, -0.01em
+ - Body/labels: 14px
+ - Compact UI (sidebar, pills, badges): 13px, 0.005em tracking
+ - Captions/meta: 12px
+ - Micro labels (status pills, section headers): 10-11px uppercase, 0.08-0.12em tracking
+ - Monospace (logs, IDs, timestamps): JetBrains Mono, 11-12px
+
+## Color Tokens
+
+### Light mode (`:root` default)
+
+| Token | Value | Purpose |
+|---|---|---|
+| `--bg` | `#fbfbfb` | App background |
+| `--panel` | `#ffffff` | Card/sidebar surfaces |
+| `--panel-soft` | `#f4f5f5` | Active/hover states |
+| `--text` | `#1a202c` | Primary text |
+| `--muted` | `#718096` | Secondary/caption text |
+| `--muted-strong` | `#4a5568` | Emphasized secondary text |
+| `--accent` | `#c06a3a` | Warm terracotta — primary action color (~4.6:1 on white) |
+| `--accent-soft` | `#f7ece6` | Accent background tint |
+| `--danger` | `#e5484d` | Errors, destructive actions |
+| `--warn` | `#b7791f` | Warnings, budget alerts |
+| `--success` | `#2f855a` | Positive states, healthy budgets |
+| `--success-soft` | `#edf7f0` | Success background tint |
+| `--line` | `rgba(15,23,42,0.08)` | Subtle borders |
+| `--line-strong` | `rgba(15,23,42,0.14)` | Emphasized borders |
+
+### Dark mode (`[data-theme="dark"]` and `prefers-color-scheme: dark` when `data-theme="system"`)
+
+| Token | Value |
+|---|---|
+| `--bg` | `#111315` |
+| `--panel` | `#1b1f23` |
+| `--panel-soft` | `#232931` |
+| `--text` | `#f4f7fb` |
+| `--muted` | `#9aa7b5` |
+| `--accent` | `#ee8a58` |
+| `--accent-soft` | `rgba(238,138,88,0.14)` |
+
+Dark mode is fully implemented via `data-theme` attribute on `:root`, with a `prefers-color-scheme` media query for the `"system"` setting.
+
+## Accent Color
+
+The warm terracotta accent (`#c06a3a` light / `#ee8a58` dark) is the signature color. Use it only for:
+- Active navigation items (icon fill + label)
+- Primary action buttons
+- Focus rings
+
+Everything else is greyscale. Overuse dilutes the signal.
+
+## Focus Ring
+
+```css
+.focus-ring:focus-visible {
+ box-shadow: 0 0 0 1px rgba(192,106,58,0.5), 0 0 0 4px rgba(192,106,58,0.12);
+ border-color: rgba(192,106,58,0.35);
+}
+```
+
+## Layout Model
+
+- Left sidebar: 220px fixed, keyboard-navigable
+- Main content: max-width 1040px centered, 40px horizontal / 32px vertical padding
+- Section spacing: 56px between major sections
+
+## Spacing & Radius
+
+- Interactive controls: 6-8px border radius
+- Cards/panels: 10px border radius
+- Dividers: 1px `var(--line)` borders, no heavy card shadows
+
+## Animation
+
+All transitions use `cubic-bezier(0.16, 1, 0.3, 1)` (ease-out-expo feel).
+
+| Context | Duration |
+|---|---|
+| Hover/focus | 150ms (`duration-150`) |
+| Page transitions | 240ms, y-axis slide (12px in, -10px out) |
+| Panel reveals | 220ms, height or y-axis |
+
+Respect `prefers-reduced-motion` globally — durations collapse to `0.01ms` when set.
+
+## Icon System
+
+Phosphor Icons (`@phosphor-icons/react`), weight `regular` by default, `fill` for active/selected states. Standard size 16-18px. Active sidebar icons use `--accent` color.
+
+## Design Principles
+
+1. **Hierarchy before density** — Typography, spacing, and color create visual hierarchy; never rely on borders alone.
+2. **Quiet until needed** — Default state is calm and minimal. Warnings and errors earn their visual weight through color and placement.
+3. **One accent, used with intent** — Terracotta is reserved for active navigation, primary actions, and focus states.
+4. **Native-feeling, not native-copying** — macOS-aware (drag regions, traffic lights) but not AppKit imitation.
+5. **Content over chrome** — The user's agents, tasks, and runs are the content. Minimize decorative scaffolding.
+
+## Required Screens
+
+Overview · Connectors · Agents · Tasks · Task Detail · Approvals · Costs · Activity · Workspaces · Settings · Onboarding
+
+## Desktop-Specific Behaviors
+
+- `Cmd` (macOS) / `Ctrl` (Windows/Linux) for search, command palette, save, refresh
+- Context menus on list rows and workspace rows
+- Drag/drop for workspace import and artifact attachment
+- Reveal in Finder/Explorer for logs and artifacts
diff --git a/docs/07-renderer-implementation.md b/docs/07-renderer-implementation.md
new file mode 100644
index 00000000..9295b5a9
--- /dev/null
+++ b/docs/07-renderer-implementation.md
@@ -0,0 +1,38 @@
+# Phase 6: FrontendDeveloper Renderer Implementation
+
+## Stack
+
+- React `19`
+- TypeScript
+- Vite / electron-vite
+- Framer Motion for shell transitions and utility drawer motion
+
+## Renderer Responsibilities Implemented
+
+- first-launch onboarding for company bootstrap and workspace selection
+- persistent desktop shell with section navigation
+- command palette toggle and keyboard-driven navigation hooks
+- connector registry with status, version, auth posture, and configuration surfaces
+- company, agent, goal, project, task, approval, cost, activity, workspace, and settings panels
+- run console utility drawer with live status and log retrieval
+- empty, loading, and error states for first-run and operational flows
+
+## State Model
+
+- snapshot-driven renderer state sourced from `window.agentCompany.loadSnapshot()`
+- local UI state for section selection, command palette visibility, console visibility, dialog drafts, and selection state
+- event subscription via `window.agentCompany.subscribe(...)` for domain changes and run updates
+
+## Desktop-Native UX Decisions
+
+- shell layout assumes resizable desktop windows, not mobile breakpoints
+- keyboard shortcuts are routed from the application menu into renderer event handling
+- workspace opening and log access are explicit desktop actions
+- drawer, inspector, and list/detail panels remain visible at desktop densities
+
+## Key Files
+
+- [App.tsx](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/src/renderer/App.tsx)
+- [main.tsx](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/src/renderer/main.tsx)
+- [styles.css](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/src/renderer/styles.css)
+- [index.html](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/src/renderer/index.html)
diff --git a/docs/08-main-process-implementation.md b/docs/08-main-process-implementation.md
new file mode 100644
index 00000000..35ad78a4
--- /dev/null
+++ b/docs/08-main-process-implementation.md
@@ -0,0 +1,35 @@
+# Phase 7: BackendDeveloper Main Process And Preload Implementation
+
+## Main Process Responsibilities Implemented
+
+- single-instance lock with focus restoration on second launch
+- secure `BrowserWindow` creation with `contextIsolation: true`, `nodeIntegration: false`, and `sandbox: true`
+- custom `app://` protocol for packaged renderer content
+- application menu, accelerators, native dialogs, and notifications
+- typed IPC registration with sender validation and schema validation
+- local SQLite profile bootstrap, backup, restore, and settings persistence
+- utility-process orchestration worker for run execution and log/status fan-out
+- updater wiring via `electron-updater`, gated by settings and environment
+
+## Preload Bridge
+
+- single exposed surface: `window.agentCompany`
+- no raw Node.js or Electron APIs exposed to renderer
+- typed invoke helpers only
+- renderer event subscription returns unsubscribe function and hides raw Electron event objects
+
+## Storage And Secrets
+
+- `node:sqlite` database under profile directory
+- WAL enabled
+- logs, artifacts, and backups stored as profile files
+- secrets encrypted with Electron `safeStorage` when available, otherwise vault fallback
+
+## Key Files
+
+- [index.ts](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/src/main/index.ts)
+- [database.ts](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/src/main/database.ts)
+- [vault.ts](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/src/main/vault.ts)
+- [worker.ts](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/src/main/orchestrator/worker.ts)
+- [index.ts](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/src/preload/index.ts)
+- [contracts.ts](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/src/shared/contracts.ts)
diff --git a/docs/09-build-verification.md b/docs/09-build-verification.md
new file mode 100644
index 00000000..c0050dbe
--- /dev/null
+++ b/docs/09-build-verification.md
@@ -0,0 +1,41 @@
+# Phase 8: BuildVerificationEngineer Validation
+
+## Commands Run
+
+```sh
+pnpm --filter @paperclipai/agent-company lint
+pnpm --filter @paperclipai/agent-company typecheck
+pnpm --filter @paperclipai/agent-company test:run
+pnpm --filter @paperclipai/agent-company build:dir
+```
+
+## Results
+
+- lint: passed (0 errors, 0 warnings)
+- typecheck: passed
+- unit tests: passed
+- integration tests: passed
+- Electron smoke E2E: passed
+- macOS directory packaging: passed
+
+## Validation Refresh (2026-03-13)
+
+- reran the full gate locally on macOS:
+ - `pnpm lint`
+ - `pnpm typecheck`
+ - `pnpm test:run`
+ - `pnpm build:dir`
+- all commands passed without blocking errors
+- package output again completed with ad-hoc macOS signing and no notarization credentials
+
+## Packaging Notes
+
+- `build:dir` now routes through [build-desktop.mjs](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/scripts/build-desktop.mjs)
+- default local packaging disables automatic signing identity discovery unless explicitly overridden
+- macOS packaging completed with ad-hoc signing fallback and skipped notarization when notarization credentials were not configured
+- custom app icons are now provided through [electron-builder.yml](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/electron-builder.yml) and [assets](/Users/zacharyzhang/Documents/Github/paperclip/AgentCompany/assets)
+
+## Platform Verification Boundary
+
+- verified on local macOS host
+- Windows and Linux packaging configuration exists but was not executed on this host
diff --git a/docs/10-code-review-and-performance.md b/docs/10-code-review-and-performance.md
new file mode 100644
index 00000000..572cab29
--- /dev/null
+++ b/docs/10-code-review-and-performance.md
@@ -0,0 +1,41 @@
+# Phase 9: Code Reviewer
+
+## Correctness Fixes Applied
+
+- removed `better-sqlite3` from the desktop runtime and replaced it with `node:sqlite`
+- fixed packaged runtime resolution for `electron-log/main.js`
+- bundled local adapter workspace packages into the main-process build instead of leaving
+ broken runtime imports behind after packaging
+- hardened trusted-sender checks for IPC invocation
+- pinned connector commands to audited runtime defaults instead of accepting arbitrary renderer
+ overrides
+- scoped secrets to companies and resolved secret bindings by `companyId`
+- validated worker messages at runtime instead of trusting unchecked casts
+- closed a test coverage gap where `*.test.ts` files were present but excluded from Vitest
+
+## Runtime Review
+
+- renderer responsiveness is acceptable for the current feature set, but continued extraction
+ of shell sections into smaller components remains a maintenance priority
+- heavy agent execution stays out of the renderer through the utility process boundary
+- background database work is local and bounded; privileged tasks do not run directly in the
+ renderer
+- critical run lifecycle writes now execute transactionally
+- lint baseline is now warning-free via `eslint.config.mjs` and `pnpm lint`
+
+## Remaining Performance Risks
+
+- the renderer bundle is still large enough that future work should split heavier sections and
+ defer rarely used surfaces
+- cross-platform production profiling has not yet been run on Windows and Linux hardware
+
+## Performance Snapshot (2026-03-13)
+
+- renderer JS bundle (`out/renderer/assets/index-*.js`): 1,162,405 bytes (~1.11 MB)
+- renderer CSS bundle (`out/renderer/assets/index-*.css`): 43,344 bytes (~42.3 KB)
+- main bundle (`out/main/index.js`): ~142.9 KB
+- main connector chunk (`out/main/chunks/connectors-*.js`): ~146.2 KB
+- preload bundle (`out/preload/index.js`): ~137.7 KB
+
+The primary optimization target remains renderer bundle splitting and lazy-loading of low-frequency
+surfaces.
diff --git a/docs/11-security-audit.md b/docs/11-security-audit.md
new file mode 100644
index 00000000..6b451525
--- /dev/null
+++ b/docs/11-security-audit.md
@@ -0,0 +1,56 @@
+# Phase 10: Security Auditor
+
+## Security Posture
+
+The desktop app now follows the required Electron baseline:
+
+- `contextIsolation: true`
+- `nodeIntegration: false`
+- `sandbox: true`
+- minimal preload bridge
+- no direct renderer access to filesystem, shell, or process APIs
+
+## Verified Controls
+
+- IPC channels are explicitly named and typed in `src/shared/contracts.ts`
+- privileged handlers validate payloads with Zod on the main-process side
+- IPC invocation is rejected for untrusted sender frames
+- `window.open` and `webview` attachment are denied
+- navigation outside approved content is blocked
+- packaged renderer content is served through a controlled `app://` protocol handler with path
+ traversal protection
+- `openPath` is restricted to managed workspace, log, artifact, backup, and profile paths
+- connector execution commands are pinned to the audited connector binary instead of renderer
+ overrides
+- secrets are company-scoped and secret binding resolution is company-aware
+- `safeStorage` is required for production secret writes; the insecure vault fallback is limited
+ to explicit test environments
+- worker-to-main messages are validated at runtime before mutating run state
+- **TODO**: Electron binary fuse hardening is NOT yet configured. Before public release,
+ add `@electron/fuses` to disable `runAsNode`, `NODE_OPTIONS` / inspect CLI argument injection,
+ enforce app-from-ASAR loading, and enable ASAR integrity validation
+
+## Release Hygiene
+
+- local builds do not auto-discover signing identities unless explicitly configured
+- desktop packaging defaults to `--publish never` to prevent accidental channel publication from local/CI build jobs
+- updater configuration remains present but still requires a real trusted update endpoint before
+ public distribution
+- notarization and production signing credentials are intentionally external to source control
+
+## Open Release Conditions
+
+The app is appropriate for internal alpha and signed beta preparation. Public production release
+still requires:
+
+- real signing credentials per platform
+- notarization on macOS
+- trusted update hosting
+- platform-native validation for Windows and Linux installers
+
+## Re-Verification Notes (2026-03-13)
+
+- reran lint, typecheck, tests, and macOS directory packaging with no security regressions
+- static source review confirmed no renderer-side `eval` / `new Function` usage
+- privileged surface remains preload-bridged through typed IPC channels only
+- `child_process.spawn` usage stays in main process and is constrained to connector command checks
diff --git a/docs/12-release-readiness.md b/docs/12-release-readiness.md
new file mode 100644
index 00000000..09df35c6
--- /dev/null
+++ b/docs/12-release-readiness.md
@@ -0,0 +1,199 @@
+# Phase 11: ProjectManager Release Readiness
+
+## Milestone Status
+
+- architecture freeze: complete
+- interactive prototype: complete
+- internal alpha desktop shell: complete
+- macOS local packaging validation: complete
+- signed beta build: pending signing/notarization credentials and platform-host verification
+- release candidate: pending Windows and Linux package validation
+- production release readiness: pending platform signing completion and final release-channel credentials
+
+## What Is Ready
+
+- dedicated Electron-native desktop workspace under `AgentCompany`
+- explicit main / preload / renderer / shared separation
+- local-first profile, secret storage, orchestration worker, IPC contracts, and desktop shell
+- onboarding to first usable shell flow
+- packaging configuration for macOS, Windows, and Linux
+- warning-free local lint baseline across main/preload/renderer
+- validation gate rerun on 2026-03-13 passed (`lint`, `typecheck`, `test:run`, `build:dir`)
+- **TODO**: PR CI quality gate workflow (`.github/workflows/agent-company-pr-verify.yml`) has not been created yet
+- **TODO**: Electron production fuse hardening has not been configured yet (see doc 11)
+- packaging script now defaults to `--publish never` unless explicitly overridden (`AGENTCOMPANY_ELECTRON_PUBLISH` or explicit `--publish`)
+
+## Release Ownership Boundaries
+
+| Area | Primary owner | Backup owner | Scope boundary | Exit evidence |
+| --- | --- | --- | --- | --- |
+| Release gate decision | CEO / ProjectManager | Product lead | Approves go/no-go only after all gates are green; does not bypass security/platform sign-off | Signed release checklist + release tag decision |
+| Signing credentials | Security Auditor | Platform Release Engineer | Manages cert issuance/rotation and secret distribution; build operators never commit secrets | Secret inventory record + cert expiry check |
+| macOS signing + notarization | macOS Release Engineer | Security Auditor | Runs signed build on macOS host and validates notarization ticket | `spctl`, `codesign`, `stapler` evidence |
+| Windows signing + installer trust | Windows Release Engineer | Security Auditor | Runs NSIS build on Windows host and validates Authenticode chain | `Get-AuthenticodeSignature` evidence |
+| Linux package validation | Linux Release Engineer | QA lead | Builds and smoke-tests AppImage on Linux host; verifies runtime dependencies | AppImage launch and smoke checklist |
+| Updater endpoint trust | Security Auditor | SRE / Infra | Owns TLS/domain trust policy and update channel integrity checks | `latest*.yml` metadata + artifact hash verification |
+| Cross-platform functional smoke | QA lead | Platform engineers | Verifies startup/onboarding/task-run/approval flows on each target OS | Smoke run logs + screenshots |
+
+## Release Checklist (Production Candidate)
+
+- [ ] `pnpm install --frozen-lockfile` completed on release host
+- [ ] `pnpm lint` passed
+- [ ] `pnpm typecheck` passed
+- [ ] `pnpm test:run` passed
+- [ ] `pnpm build:dir` passed
+- [ ] signing environment variables are set from secret manager (not shell history files)
+- [ ] `AGENTCOMPANY_UPDATE_URL` points to production or staging trusted domain (not `example.invalid`)
+- [ ] updater checks are enabled for release validation (`AGENTCOMPANY_DISABLE_UPDATES=false`)
+- [ ] macOS signed build + notarization validation completed on macOS host
+- [ ] Windows signed installer validation completed on Windows host
+- [ ] Linux AppImage validation completed on Linux host
+- [ ] update metadata (`latest*.yml`) and published artifacts hash-match
+- [ ] secrets regression check completed (existing local secrets remain readable after upgrade)
+- [ ] local data migration test completed (old profile boots and migrates without data loss)
+- [ ] final go/no-go approved by CEO / ProjectManager
+
+## Runbook
+
+### 1. Preflight (all platforms)
+
+```sh
+pnpm install --frozen-lockfile
+pnpm lint
+pnpm typecheck
+pnpm test:run
+pnpm build:dir
+```
+
+Expected: all commands pass; no skipped failures are allowed unless explicitly waived in release notes.
+
+### 2. Signing Material Readiness
+
+Prepare these values in CI secret manager or local secure vault:
+
+- `AGENTCOMPANY_UPDATE_URL`
+- `CSC_LINK`
+- `CSC_KEY_PASSWORD`
+- `WIN_CSC_LINK`
+- `WIN_CSC_KEY_PASSWORD`
+- macOS notarization credentials (`APPLE_ID`, `APPLE_APP_SPECIFIC_PASSWORD`, `APPLE_TEAM_ID`) if using Apple ID flow
+
+Sanity check before release build:
+
+```sh
+env | rg "^(AGENTCOMPANY_UPDATE_URL|CSC_LINK|WIN_CSC_LINK|APPLE_ID|APPLE_TEAM_ID)="
+```
+
+### 3. macOS Signed Build + Notarization (native macOS host)
+
+1. Enable release-mode updater behavior and set trusted update URL.
+2. Build signed artifacts.
+3. Validate signature + notarization ticket.
+
+```sh
+export AGENTCOMPANY_DISABLE_UPDATES=false
+export AGENTCOMPANY_UPDATE_URL="https://updates./agentcompany/stable"
+export CSC_LINK="file://$HOME/.signing/agentcompany-mac.p12"
+export CSC_KEY_PASSWORD=""
+export CSC_IDENTITY_AUTO_DISCOVERY=true
+export APPLE_ID=""
+export APPLE_APP_SPECIFIC_PASSWORD=""
+export APPLE_TEAM_ID=""
+
+pnpm build -- --mac dmg zip --publish never
+
+spctl -a -vv "build/release/mac/AgentCompany.app"
+codesign -dv --verbose=4 "build/release/mac/AgentCompany.app" 2>&1 | rg "Authority=|TeamIdentifier="
+xcrun stapler validate "build/release"/*.dmg
+```
+
+Notes:
+
+- For public macOS distribution, switch `mac.hardenedRuntime` to `true` with proper entitlements before final GA build.
+- Keep ad-hoc signing only for local development and internal unsigned testing.
+
+### 4. Windows Signed Installer Validation (native Windows host)
+
+```powershell
+$env:AGENTCOMPANY_DISABLE_UPDATES = "false"
+$env:AGENTCOMPANY_UPDATE_URL = "https://updates./agentcompany/stable"
+$env:WIN_CSC_LINK = "C:\signing\agentcompany-win.pfx"
+$env:WIN_CSC_KEY_PASSWORD = ""
+
+pnpm build -- --win nsis --x64 --publish never
+
+Get-ChildItem .\build\release\*.exe | Get-AuthenticodeSignature |
+ Format-Table Path, Status, @{Name='Signer';Expression={$_.SignerCertificate.Subject}}
+```
+
+Expected:
+
+- `Status` is `Valid`
+- signer subject matches the intended publisher identity
+
+### 5. Linux AppImage Validation (native Linux host)
+
+```sh
+export AGENTCOMPANY_DISABLE_UPDATES=false
+export AGENTCOMPANY_UPDATE_URL="https://updates./agentcompany/stable"
+
+pnpm build -- --linux AppImage --x64 --publish never
+
+chmod +x build/release/*.AppImage
+./build/release/*.AppImage --appimage-version
+```
+
+Then run manual smoke validation on Linux:
+
+- app launches and reaches main shell
+- company/workspace/agent CRUD works
+- task run + approval flow works
+- settings toggle for updater works
+
+### 6. Updater Endpoint Trust Verification
+
+1. Validate update metadata endpoint and schema.
+2. Verify published artifact hash against metadata.
+3. Validate app update check in runtime.
+
+```sh
+curl -fsSL "$AGENTCOMPANY_UPDATE_URL/latest.yml" -o /tmp/latest.yml
+rg "^(version|path|sha512):" /tmp/latest.yml
+```
+
+Hash verification (replace placeholders with actual artifact path/hash from metadata):
+
+```sh
+node -e "const fs=require('fs');const crypto=require('crypto');const [file,expected]=process.argv.slice(1);const got=crypto.createHash('sha512').update(fs.readFileSync(file)).digest('base64');if(got!==expected){console.error('sha512 mismatch');process.exit(1)}console.log('sha512 ok');" \
+ build/release/ \
+ ""
+```
+
+Runtime verification:
+
+- launch packaged app with `AGENTCOMPANY_DISABLE_UPDATES=false`
+- trigger `Check for updates` from Settings
+- confirm request goes only to trusted `AGENTCOMPANY_UPDATE_URL` domain
+- confirm unsigned/untrusted update payloads are rejected by platform signing checks
+
+### 7. Windows/Linux Native-Host QA Gate
+
+Required evidence per platform:
+
+- startup success + no crash in first 5 minutes
+- create company + create workspace + create task + assign agent + run once
+- approve one pending approval item
+- inspect logs for uncaught errors
+- close/reopen app and confirm local data persistence
+
+### 8. Release Close-Out
+
+- publish artifacts and corresponding `latest*.yml` only after all platform owners sign off
+- attach evidence bundle (command output, screenshots, hash checks, signatures)
+- mark release decision in changelog/release note with approver and timestamp
+
+## Outstanding Risks Before Public GA
+
+- current config keeps `mac.hardenedRuntime: false`; must be enabled with release entitlements for notarized public mac builds
+- no trusted production updater endpoint is configured by default (`example.invalid` fallback)
+- Windows and Linux validation still requires native host execution each release cycle
diff --git a/electron-builder.yml b/electron-builder.yml
new file mode 100644
index 00000000..4359106e
--- /dev/null
+++ b/electron-builder.yml
@@ -0,0 +1,34 @@
+appId: com.agentcompany.desktop
+productName: AgentCompany
+directories:
+ buildResources: assets
+ output: build/release
+files:
+ - out/**
+ - package.json
+asar: true
+icon: assets/icon.png
+mac:
+ category: public.app-category.developer-tools
+ icon: assets/icon.icns
+ target:
+ - dmg
+ - zip
+ # hardenedRuntime requires a real code signing identity.
+ # For local/unsigned builds, keep it off. Enable when signing is configured.
+ hardenedRuntime: false
+win:
+ icon: assets/icon.ico
+ target:
+ - nsis
+linux:
+ icon: assets/icon.png
+ target:
+ - AppImage
+nsis:
+ oneClick: false
+ perMachine: false
+ allowToChangeInstallationDirectory: true
+publish:
+ provider: generic
+ url: ${AGENTCOMPANY_UPDATE_URL:-https://updates.example.invalid/agentcompany}
diff --git a/electron.vite.config.ts b/electron.vite.config.ts
new file mode 100644
index 00000000..77d3baef
--- /dev/null
+++ b/electron.vite.config.ts
@@ -0,0 +1,62 @@
+import { resolve } from "node:path";
+import react from "@vitejs/plugin-react";
+import tailwindcss from "@tailwindcss/vite";
+import { defineConfig, externalizeDepsPlugin } from "electron-vite";
+
+const bundledMainDependencies = [
+ "@agentcompany/adapter-claude-local",
+ "@agentcompany/adapter-codex-local",
+ "@agentcompany/adapter-gemini-local",
+ "@agentcompany/adapter-opencode-local",
+ "@agentcompany/adapter-utils",
+];
+
+export default defineConfig({
+ main: {
+ plugins: [externalizeDepsPlugin({ exclude: bundledMainDependencies })],
+ resolve: {
+ alias: {
+ "@shared": resolve("src/shared"),
+ "@main": resolve("src/main"),
+ },
+ },
+ build: {
+ rollupOptions: {
+ input: {
+ index: resolve("src/main/index.ts"),
+ worker: resolve("src/main/orchestrator/worker.ts"),
+ },
+ },
+ },
+ },
+ preload: {
+ plugins: [externalizeDepsPlugin({ exclude: ["zod"] })],
+ resolve: {
+ alias: {
+ "@shared": resolve("src/shared"),
+ "@preload": resolve("src/preload"),
+ },
+ },
+ build: {
+ rollupOptions: {
+ input: {
+ index: resolve("src/preload/index.ts"),
+ },
+ output: {
+ format: "cjs",
+ entryFileNames: "[name].js",
+ chunkFileNames: "chunks/[name]-[hash].js",
+ },
+ },
+ },
+ },
+ renderer: {
+ resolve: {
+ alias: {
+ "@shared": resolve("src/shared"),
+ "@renderer": resolve("src/renderer"),
+ },
+ },
+ plugins: [react(), tailwindcss()],
+ },
+});
diff --git a/eslint.config.mjs b/eslint.config.mjs
new file mode 100644
index 00000000..c03b81e3
--- /dev/null
+++ b/eslint.config.mjs
@@ -0,0 +1,65 @@
+import js from "@eslint/js";
+import globals from "globals";
+import reactHooks from "eslint-plugin-react-hooks";
+import reactRefresh from "eslint-plugin-react-refresh";
+import tseslint from "typescript-eslint";
+
+export default tseslint.config(
+ {
+ ignores: [
+ "out/**",
+ "build/**",
+ "dist/**",
+ "node_modules/**",
+ "test-results/**",
+ "playwright-report/**",
+ "coverage/**",
+ ],
+ },
+ js.configs.recommended,
+ ...tseslint.configs.recommended,
+ {
+ files: ["src/**/*.{ts,tsx}", "tests/**/*.{ts,tsx}", "scripts/**/*.{ts,mjs}", "packages/**/*.{ts,tsx}"],
+ languageOptions: {
+ ecmaVersion: "latest",
+ sourceType: "module",
+ parserOptions: {
+ ecmaFeatures: {
+ jsx: true,
+ },
+ },
+ globals: {
+ ...globals.node,
+ ...globals.browser,
+ },
+ },
+ plugins: {
+ "react-hooks": reactHooks,
+ "react-refresh": reactRefresh,
+ },
+ rules: {
+ ...reactHooks.configs.recommended.rules,
+ "react-refresh/only-export-components": "off",
+ "@typescript-eslint/no-unused-vars": [
+ "warn",
+ {
+ argsIgnorePattern: "^_",
+ varsIgnorePattern: "^_",
+ caughtErrorsIgnorePattern: "^_",
+ },
+ ],
+ "@typescript-eslint/no-explicit-any": "off",
+ "react-hooks/exhaustive-deps": "warn",
+ "react-hooks/set-state-in-effect": "off",
+ "react-hooks/refs": "off",
+ },
+ },
+ {
+ files: ["tests/**/*.{ts,tsx}"],
+ languageOptions: {
+ globals: {
+ ...globals.vitest,
+ },
+ },
+ }
+);
diff --git a/homepagedesign.html b/homepagedesign.html
new file mode 100644
index 00000000..39e7aa81
--- /dev/null
+++ b/homepagedesign.html
@@ -0,0 +1,436 @@
+
+
+
+ Dashboard
+
+
+
+
+
+
+
+
+
+
+
Overview
+
+
+
+
Current Performance
+
Metrics from the last 30 days.
+
+
+
+ Total Views
+ 124,500
+
+
+ Engagement Rate
+ 4.2%
+
+
+ Active Users
+ 8,192
+
+
+
+
+
+
Recent Activity
+
Latest actions across your workspace.
+
+
+
+ Activity Feed
+ View all
+
+
+
+
+
+
J
+
+ John Smith updated Profile
+ 2 hours ago • Settings
+