Project: pvybutler (/Volumes/Data/Repos/pvybutler)
Date: 2026-07-26
Models: Qwen 3.6 35B MoE · GLM-5.2 756B MoE · DeepSeek V4 Pro 1.6T
Status: Draft
Refactor the pvybutler codebase across 4 tracks: Brand renaming, Security hardening, Performance optimization, and Routes/Pipeline restructuring. Each track runs as a specialist team in a coordinated swarm, with handoffs between teams.
pvybutler is a TypeScript/Node.js Electron monorepo:
apps/web — Standalone React UI (Vite + React Router + Zustand + Tailwind + shadcn/ui)apps/desktop — Thin Electron shell (main process + preload), loads web’s build outputpackages/agent-core — Core business logic, types, storage, MCP tools (ESM)apps/daemon — Long-lived background process that owns task execution, spawns opencode serve subprocesses
¶ Track 1: Brand (Accomplish → PVYbutler)
Specialist: brand-refactor (Qwen 3.6)
Skill: brand-rename-checklist
- Package names:
@accomplish/* → @pvybutler/*
- Environment variables:
ACCOMPLISH_* → PVYBUTLER_*
- Display strings: window titles, tray icon, about dialog, PWA manifest
- Documentation: README (all language variants), CONTRIBUTING, SECURITY, TRADEMARKS
- CI/CD: workflow names, artifact names
- Released migration files (immutable)
- Third-party dependency names
- Git history (no rewrites)
Specialist: security-audit (GLM-5.2, Think High)
Skill: security-scan
- AES-256-GCM encryption: key derivation, IV uniqueness, auth tag verification
- Electron IPC: context isolation, node integration, preload bridge
- IPC handlers: input validation, no raw file system access, no shell execution
- Rate limiting: per-IP/per-token limits, bypass prevention
- Secrets handling: no logging, no command-line args, encryption at rest
- Subprocess spawning: environment sanitization, workspace isolation, timeouts
- Network-level security (TLS, certificate pinning — handled by Electron)
- Dependency vulnerability scanning (use
pnpm audit separately)
Specialist: perf-optimizer (DeepSeek V4 Pro, Think Max)
Skill: perf-profiler
- Bundle size: web UI chunk analysis, tree-shaking, code splitting
- IPC overhead: synchronous handlers, large payloads, batchable calls
- Daemon route latency: blocking I/O, connection pooling, N+1 patterns
- Scheduler: queue type, task timeout, starvation prevention
- Storage migrations: synchronous vs incremental, worst-case time
- Memory: main process, renderer, leak detection
- Task event forwarding: polling vs streaming, backpressure
- Frontend CSS/animation performance (separate UI optimization)
- Network latency to external APIs (can’t control)
Specialist: routes-refactor (Qwen 3.6)
Skill: routes-api-conformance
- REST conformance: HTTP methods, status codes, error format
- Input validation: body, params, query, Content-Type
- Task pipeline: lifecycle events, callback patterns, dead code removal
- Connector service: interface cleanup, method visibility
- Health endpoint: readiness vs liveness, subsystem checks
- Adding new routes/features (this is a refactor, not feature work)
- Changing the daemon’s external API contract (backwards compatible)
- Database schema changes
Specialist: ts-test-writer (Qwen 3.6)
- Unit tests for all modified modules in agent-core
- Integration tests for modified IPC handlers
- Web component tests for modified UI
- Integration tests for storage migrations
- Integration tests for rate limiter under load
1. Brand (Team: brand)
↓ handoff
2. Security (Team: security)
↓ handoff
3. Performance + Routes (Team: perf-routes) — parallel within team
↓ handoff
4. Test Writer (across all teams)
↓ final
5. Code Review (built-in code-review specialist)
- Brand rename breaks imports: Mitigated by running
pnpm typecheck after each category
- Security fixes break tests: Mitigated by running tests after each fix
- Performance changes introduce regressions: Mitigated by measuring before/after
- Route changes break API consumers: Mitigated by backwards-compatible approach (new routes alongside old, deprecate old)
- Swarm context overhead: Each specialist starts fresh — tasks must be self-contained
- Database schema migrations (create new, don’t modify existing)
- UI redesign (only brand-related display string changes)
- Adding new features
- Dependency upgrades (separate task)
- E2E test changes (manual review after all tracks complete)