audit(capsule): batch 6 + exec summary + phase-2 plan update (51/272 = 18.8%)

Batch 6 — pc2-node/src/utils/ (16/16 complete, 1 already-pilot-audited):
- 9 A: logger, polyfill, routes, wallet, skill-parser, redact, rpc,
       secureViewSession, platform.
- 5 A-: encryption, urlUtils, fileUrlSigner, respawner, metrics.
- 2 B: runtime-heartbeat (pilot), binary-manager (969 LOC, multi-capability
       downloader+verifier+installer).

Role-based hypothesis strongly confirmed at the utility level (14/16
= 87.5% A or A-). The one B-class new entry (binary-manager) is a
multi-capability orchestrator masquerading as a utility. Surfaced the
8th instance of the concrete-class-import blocker (metrics.ts uses
DatabaseManager).

NEW: AUDIT_EXECUTIVE_SUMMARY.md (126 lines)
A 3-minute-read companion to the 676-line full report. Captures the
5 most important findings for Sasha / Anders / Ahmed / board narrative.
Each finding has a one-line implication. TL;DR at top, strategic verdict
at bottom, audience-specific reading guide.

PHASE-2-PLAN.md Cluster 5 — updated with concrete module names from the
audit instead of speculation:
- 5.1: marked IN PROGRESS with 51/272 status, distribution stats, 4
  concrete actionable findings already extractable for Phase 2 tickets.
- 5.2: marked PARTIALLY DONE (subsumed by 5.1; the capability audit
  doubled as the affordance audit).
- 5.3 (NEW): concrete-class → interface extraction ticket — 1 week of
  work, fixes 9+ module scores in one coordinated PR set.
- 5.4 (NEW): types extraction (providers/types.ts + storage/types.ts) —
  ~3 hours total, +1 score on 9 modules.

The audit has now produced enough concrete data to drive specific
Phase 2 tickets rather than aspirational descriptions.

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: SashaMIT

.cursor/tasks/OPTIMISATION-AND-REFACTORING-2026-05/AUDIT_EXECUTIVE_SUMMARY.md

@@ -0,0 +1,126 @@
+# Capsule Readiness Audit — Executive Summary
+
+> **Companion to**: [`CAPSULE_READINESS_REPORT.md`](./CAPSULE_READINESS_REPORT.md) (full audit data, methodology, 638-line per-module classification).
+> **For**: Sasha, Anders (Runtime team), Ahmed (ENM), board narrative.
+> **Reading time**: 3 minutes.
+> **Status**: Audit-in-progress; 51 of 272 pc2-node modules classified (18.8%); strategy stable.
+> **Updated**: 2026-05-16.
+
+---
+
+## TL;DR
+
+pc2-node is **more capsule-ready than expected**. After auditing 51 modules across 6 subtrees:
+
+- **75% of audited modules are A or A- class** (capsule-ready or close to it)
+- **Only 2 modules are deeply coupled** (C-class): `ConnectivityService` and `api/index.ts` — both mega-orchestrators that the Runtime architecture eliminates by design
+- **The ElastOS Runtime capability vocabulary already exists** inside pc2-node and is **already being enforced** at the HTTP boundary
+- **Migration is role-scoped, not subtree-scoped** — lift A-class leaves in parallel across all subtrees; refactor B-class orchestrators in bounded chunks; redesign the 2 C-class mega-orchestrators last
+
+Runtime convergence is **extension of existing structure, not greenfield invention**. The dual-track strategy from `AGENTIC-PC2-MONETISATION-2026-05` is supported by empirical evidence.
+
+---
+
+## The five findings that matter
+
+### Finding 1: The capability vocabulary already exists
+
+`pc2-node/src/types/capabilities.ts` defines a 14-scope capability vocabulary (`storage:read`, `storage:write`, `ipfs:fetch`, `wallet:read`, `wallet:sign`, `drm:decrypt`, `drm:encrypt`, `compute:wasm`, `compute:ai`, `network:rpc`, `ipc:launch`, `ipc:message`, `identity:auth`, `ipfs:pin`). The file header states:
+
+> *Single source of truth for capability scope names used across: AppManifest.capabilities, API key scopes, Wallet bridge method classification, Runtime v2 capability token `action` fields. These map 1:1 to ElastOS Runtime provider contract operations.*
+
+**Implication**: pc2-node was designed from the start with Runtime convergence in mind. The vocabulary is in place. Whoever wrote this file was already thinking in capability-token terms.
+
+### Finding 2: The capability ENFORCEMENT already exists
+
+`pc2-node/src/api/middleware.ts` exports `requireCapability(scope: string)` middleware that gates HTTP routes using the Finding-1 vocabulary. Combined with `populatePrincipal()` and the `CapabilityPrincipal` interface, **pc2-node has a working capability-token enforcement layer at HTTP request time**.
+
+**Implication**: We don't need to *invent* capability enforcement; we need to (a) extend it to non-HTTP entry points (websocket, IPC), and (b) port the enforcement layer into the Runtime substrate. The mental model already lives in pc2-node code.
+
+### Finding 3: Capsule readiness is role-based, not subtree-based
+
+The pilot audit's framing ("AI is mostly A, connectivity is mostly C") turned out to be sampling artefact. After auditing 51 modules across 6 subtrees, the pattern is clear:
+
+- **Pure utility / protocol / type leaves** → A-class everywhere
+- **File-backed services with light direct-fs** → A- everywhere
+- **Medium orchestrators wiring sibling services** → B everywhere
+- **Mega-orchestrators with 40+ concrete imports** → C (only 2 modules; both will be retired by capsule architecture)
+
+**Implication**: Runtime migration order is decoupled from subtree boundaries. The Runtime team can lift `boson-crypto` + `ai-providers` + `storage-migrations` **in parallel as their own crates**, not sequentially per-subtree. This unblocks parallel work.
+
+### Finding 4: One refactor pattern dominates
+
+The single biggest cross-cutting blocker is **"concrete class import where an interface should suffice"** — confirmed in 9+ modules across 5 subtrees. Examples:
+- `filesystem.ts` imports concrete `IPFSStorage` + `DatabaseManager`
+- `api/wallet.ts` imports concrete `AgentKitExecutor`
+- `BosonService` imports 7 concrete sibling services
+- `metrics.ts` imports concrete `DatabaseManager`
+
+**The fix**: extract ~5-6 interfaces (`IFilesystemManager`, `IDatabaseManager`, `IIPFSStorage`, `IAIChatService`, `IAgentKitExecutor`, `IIdentityService`). One Phase 2 ticket. Improves the score of 9+ modules.
+
+**Estimated effort**: 1 week of focused work, value-positive for PC2 v1 testability and Runtime migration alike.
+
+### Finding 5: Only 2 modules are deeply coupled
+
+After 51 audits, only **two** modules earn C-class:
+- `pc2-node/src/services/boson/ConnectivityService.ts` (1,597 LOC, network-side mega-orchestrator with state machine and setter-injected services)
+- `pc2-node/src/api/index.ts` (1,766 LOC, HTTP-side mega-orchestrator wiring 40+ siblings, ambient Express coupling)
+
+Both are the same architectural pattern on opposite sides of the codebase. Both will be **retired**, not refactored, by capsule architecture (capsules don't have single mega-entry-points by design).
+
+**Implication**: the "PC2-as-monolith" problem is concentrated in 2 files. The other 49 audited modules are either capsule-shape already (38) or one bounded refactor away (11).
+
+---
+
+## The strategic verdict
+
+After 51 modules of empirical data:
+
+**Phase 1 (immediate, blocking nothing)**: Mac launcher ships. Stable for 48-72h.
+
+**Phase 2 (post-Mac, ~3-4 weeks of bounded work)**:
+- **(a) Runtime team can begin lifting A-class leaves as crates in parallel**: `boson-crypto`, `boson-protocol`, `ai-providers`, `storage-migrations`, `types-capabilities`. Low coordination cost; leaves don't change shape.
+- **(b) PC2 team can refactor B-class orchestrators in bounded chunks** (~15-20 days total):
+  - `AIChatService` split (~3-5 days)
+  - `ToolExecutor` split + capability injection (~4-5 days)
+  - `BosonService` interface extraction (~1-2 days)
+  - `filesystem.ts` + `indexer.ts` interface extraction (~1-2 days)
+  - Cross-cutting "concrete-class → interface" refactor (~1 week — touches 9+ modules)
+- **(c) Both C-class mega-orchestrators** wait for Runtime substrate; their eventual redesign retires the mega-orchestrator pattern altogether.
+
+**Phase 3 (Q4 2026 onwards)**: ConnectivityService + api/index.ts redesign happens as the Runtime substrate matures. The 2 mega-orchestrators are the last things to migrate, by design.
+
+---
+
+## What this changes about the AGENTIC-PC2-MONETISATION mandate
+
+The mandate's dual-track strategy is **supported with stronger empirical backing**:
+
+1. **Track 1 (PC2 v1 evolution)**: Work in the AI leaf modules is NOT throw-away. Those modules already match the capsule shape; they migrate cleanly.
+2. **Track 2 (Runtime convergence)**: Runtime is **not future-tense**. The vocabulary, enforcement layer, and module shape are already partly in place. Convergence is incremental extension, not greenfield rewrite.
+3. **The 8 new Rust crates identified in mandate v1.1 §7.5** can now be cross-referenced to specific pc2-node modules:
+   - `dDRM provider` capsule — sources from `services/ai/tools/` + the dDRM modules (not yet audited)
+   - `boson-crypto` capsule — sources directly from `services/boson/CryptoBox.ts` (A, 9/10)
+   - `boson-protocol` capsule — sources directly from `services/boson/ProxyProtocol.ts` (A, 10/10)
+   - `ai-providers` capsule — sources from `services/ai/providers/*.ts` (all A-class)
+   - `storage-migrations` capsule — sources from `storage/migrations.ts` (A, 9/10)
+
+---
+
+## What we DON'T yet know
+
+- 80% of pc2-node/src is still unaudited. Distribution may shift as more modules come in.
+- `services/dDRM/`, `services/ddrm/`, `services/gateway/`, `services/UpdateService.ts` — the DRM and update subsystems are not yet sampled. These could surface additional C-class entries or new patterns.
+- The 40 remaining `api/` HTTP handlers are predicted to be ~70% B / 25% A- / 5% C but unverified.
+- WebSocket subtree (`websocket/*`) has 4 modules; not yet sampled.
+
+**Audit completion plan**: extend in subtree batches per `CAPSULE_READINESS_REPORT §6`. Target 50% coverage in the May 25-29 window (post-Mac launcher). The remaining ~221 modules are ~12-15 hours of analyst-time at current pace.
+
+---
+
+## What you do with this document
+
+- **Sasha**: skim Finding 3 + 4 + the strategic verdict. Decide whether to commit to the (a)(b)(c) phasing for Phase 2.
+- **Anders / Runtime team**: skim Findings 1 + 2 (the capability infra already exists) + the strategic verdict (a). Identify which A-class crates to lift first.
+- **Ahmed / ENM**: skim Finding 1 + the cross-reference table at the bottom. The ENM integration path inherits from the same capability vocabulary.
+- **Board narrative**: TL;DR + the strategic verdict. The story is "pc2-node was architected for Runtime convergence from the start; the migration is bounded and parallelisable".