#10570: feat(plugins): TOFU integrity verification for plugins

## Human View ### Summary - Adds Trust-On-First-Use (TOFU) integrity verification for plugins via `src/plugins/integrity.ts` - On first load a plugin's manifest + tool descriptions are SHA-256 hashed and stored as a "pin" - On subsequent loads the current manifest is compared against the pin — version bumps, added/removed/modified tools are flagged so the user can review before trusting ### Motivation Plugin supply-chain attacks are a growing concern. A malicious plugin update could silently add/modify tools to exfiltrate data. TOFU provides a lightweight trust model (similar to SSH `known_hosts`) that alerts users to changes without requiring a central registry or code signing infrastructure. ### Design - **Pin store**: File-backed JSON (`Map<pluginId, PluginPin>`) — portable, human-readable - **Hashing**: SHA-256 of normalized tool descriptors (name + description + inputSchema), order-independent - **Lifecycle**: `pinPlugin` → `verifyPlugin` → `approvePlugin` / `unpinPlugin` - **Change detection**: Returns typed `IntegrityChange[]` — `version_changed`, `tool_added`, `tool_removed`, `tool_modified` ### Test plan - [x] Auto-pin on first use - [x] Trust unchanged manifest - [x] Detect modified tool description - [x] Detect added/removed tools - [x] Detect version changes - [x] Multiple simultaneous changes - [x] Approve re-pins after review - [x] Unpin removes entry - [x] Persistence round-trip (save/load) - [x] Corrupted pin file graceful fallback - [x] Tool order independence (sorted hashing) --- ## AI View (DCCE Protocol v1.0) ### Metadata - **Generator**: Claude (Anthropic) via Cursor IDE - **Methodology**: AI-assisted development with human oversight and review ### AI Contribution Summary - Code analysis and solution design - Implementation and testing ### Verification Steps Performed 1. Analyzed source code to identify root cause 2. Implemented and tested the fix ### Human Review Guidance - Core changes are in: `src/plugins/integrity.ts`, `src/plugins/integrity.test.ts` - Review the breaking change implications Made with M7 [Cursor](https://cursor.com) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> - Introduces a new TOFU-style plugin integrity system (`src/plugins/integrity.ts`) that hashes a plugin manifest + tool descriptors, stores a local “pin”, and reports version/tool diffs on subsequent loads. - Adds a Vitest suite (`src/plugins/integrity.test.ts`) covering first-use pinning, unchanged trust, change detection (version/tool add/remove/modify), approval re-pin, unpin, persistence, and tool order independence. - Stores pins in a file-backed JSON map keyed by plugin id and computes SHA-256 hashes for manifest/tool snapshots. <h3>Confidence Score: 3/5</h3> - This PR is close to merge-ready but has correctness issues that can trigger false integrity-change reports or ambiguous hashing behavior. - Core approach and tests look coherent, but hashing `inputSchema` via plain JSON.stringify is not canonical (can flag changes when none exist), and duplicate tool names are silently collapsed/overwritten, breaking integrity semantics if such manifests occur. - src/plugins/integrity.ts <!-- greptile_other_comments_section --> <!-- /greptile_comment -->