@pharaoh-so/mcp 0.3.28 → 0.3.31

package/README.md

@@ -64,45 +64,28 @@ Authentication uses [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628) (O
 
 ## Available Tools
 
-Once connected, Pharaoh provides 19 MCP tools organized into four categories:
+Once connected, Pharaoh provides these MCP tools:
 
-### Orient (Free)
+### Orient
 
 | Tool | What it answers |
 |------|----------------|
 | `get_codebase_map` | What modules exist and how do they relate? |
 | `get_module_context` | What does this module look like before I modify it? |
 | `search_functions` | Does this function already exist somewhere? |
-| `get_design_system` | What UI components and tokens already exist? |
+| `pharaoh_recon` | Map, module context, search and blast radius in one call |
 
-### Investigate (Free + Pro)
+### Investigate
 
 | Tool | What it answers |
 |------|----------------|
 | `get_blast_radius` | What breaks if I change this function/file/module? |
-| `query_dependencies` | How are these two modules connected? |
-| `check_reachability` | Is this function actually reachable from entry points? |
-| `get_vision_docs` | Is there a PRD or spec for this? |
 
-### Audit (Pro)
+### Manage
 
 | Tool | What it answers |
 |------|----------------|
-| `get_vision_gaps` | What's specified but not built? What's built but not specified? |
-| `get_cross_repo_audit` | Are shared dependencies drifting between repos? |
-| `get_consolidation_opportunities` | Where is duplicate or overlapping logic? |
-| `get_unused_code` | What code is never called and safe to delete? |
-| `get_test_coverage` | Which modules/functions lack test coverage? |
-| `get_regression_risk` | How risky is this change to production? |
-
-### Manage (Free)
-
-| Tool | What it answers |
-|------|----------------|
-| `request_upload` | Map a local repo without installing the GitHub App |
-| `setup_environment` | Install recommended development plugins |
 | `pharaoh_account` | Check plan, toggle PR Guard, trigger refresh |
-| `pharaoh_feedback` | Report false positives or tool issues |
 | `pharaoh_admin` | Org-level administration |
 
 ## Inspect Mode

package/commands/plan.md

@@ -39,12 +39,11 @@ Do NOT review from memory or assumptions. Query the actual codebase first.
 ### If Pharaoh MCP tools are available:
 
 1. `get_codebase_map` — current modules, hot files, dependency graph
-2. `get_vision_docs` — read the repo's architectural contract. If the plan touches a domain with a MUST-bullet, the assertion is a hard constraint on the plan. Raise it explicitly in Section 1. If `get_vision_docs` returns an empty-state scaffold, flag that the repo needs `/pharaoh:vision` before planning anything architectural.
+2. Read `docs/VISION.md` if the repo has one — the repo's architectural contract. If the plan touches a domain with a MUST-bullet, the assertion is a hard constraint on the plan. Raise it explicitly in Section 1.
 3. `search_functions` for keywords related to the plan — find existing code to reuse/extend
 4. `get_module_context` on affected modules — entry points, patterns, conventions
-5. `query_dependencies` between affected modules — coupling, circular deps
+5. `pharaoh_recon` with `dependencies` pairs for the affected modules — coupling, circular deps
 6. `get_blast_radius` on the primary target of the change — know what breaks
-7. `check_reachability` on the primary target — verify it's actually reachable from entry points before worrying about it
 
 ### Without Pharaoh (graceful fallback):
 
@@ -96,7 +95,6 @@ Adapt depth to change size. Skip sections that don't apply. **After each section
 
 - Are all new exports called from a production entry point?
 - Run `get_blast_radius` on any new/changed functions — zero callers = not done
-- `check_reachability` on new exports — verify reachable from API handlers, crons, or event handlers
 - Does the plan declare WHERE new code gets called from? If not, flag it
 - Integration points: how does this connect to what already exists?
 
@@ -138,7 +136,6 @@ Number each issue (1, 2, 3...) and letter each option (A, B, C...). Recommended
 
 - **Before reviewing**: recon (Step 1 above)
 - **During review**: `get_blast_radius` when evaluating impact of changes; `search_functions` before suggesting new code
-- **After decisions**: `check_reachability` on all new exports; `get_unused_code` to catch disconnections
 - **Final sweep**: `get_blast_radius` on ALL new exports — zero callers on non-entry-points = plan is incomplete
 
 ## Workflow Rules

package/commands/review.md

@@ -61,14 +61,9 @@ Call `pharaoh_recon` with:
 - **blast_radius:** The most critical changed files/functions as blast radius targets (up to 3). Pick the files with the most downstream risk — entry points, shared utilities, exported APIs.
 - **dependencies:** Pairs of touched modules to trace coupling between (up to 3)
 
-Then call these additional tools for data recon doesn't cover:
-- `get_regression_risk` — overall change risk score for the repo
-- `get_consolidation_opportunities` — duplicate logic the PR may introduce
-- `check_reachability` — are new exports wired to entry points?
-- `get_vision_docs` — read the repo's architectural contract. For every touched module, pull its relevant assertions. Any change touching code governed by a MUST-bullet must be checked against that assertion — if the change would violate the MUST, the verdict tips toward BLOCK unless VISION.md is updated in the same PR with user approval.
-- `get_vision_gaps` — do changes align with or drift from specs? New complex functions without a matching assertion are flagged; retired specs with implementing code are flagged.
+Then read `docs/VISION.md` if the repo has one — the repo's architectural contract. For every touched module, find its relevant assertions. Any change touching code governed by a MUST-bullet must be checked against that assertion — if the change would violate the MUST, the verdict tips toward BLOCK unless VISION.md is updated in the same PR with user approval.
 
-**Output of Phase 1:** Architecture map, module profiles for every touched module, blast radius for high-risk changes, dependency paths between coupled modules, regression risk level, duplication findings, reachability status, and spec alignment.
+**Output of Phase 1:** Architecture map, module profiles for every touched module, blast radius for high-risk changes, dependency paths between coupled modules, and spec alignment.
 
 ---
 
@@ -81,7 +76,7 @@ Then call these additional tools for data recon doesn't cover:
 | Agent | When to dispatch | Focus |
 |-------|-----------------|-------|
 | **Code Reviewer** | Always | Bugs, logic errors, CLAUDE.md compliance, code quality. Confidence-filtered (only issues >= 80/100). |
-| **Security Reviewer** | When changes touch auth, encryption, tokens, tenant isolation, data access, billing, webhooks, Cypher queries, or any security-sensitive surface. Also dispatch when Phase 1 regression risk is HIGH. | OWASP Top 10, injection vectors, access control bypasses, tenant isolation violations, cryptographic misuse, secret exposure, plus project-specific security rules. See checklist below. |
+| **Security Reviewer** | When changes touch auth, encryption, tokens, tenant isolation, data access, billing, webhooks, Cypher queries, or any security-sensitive surface. Also dispatch when the Phase 1 blast radius marks the change as HIGH risk. | OWASP Top 10, injection vectors, access control bypasses, tenant isolation violations, cryptographic misuse, secret exposure, plus project-specific security rules. See checklist below. |
 | **Silent Failure Hunter** | When changes touch error handling, catch blocks, fallback logic, API calls, or any code that could suppress errors | Silent failures, broad catches, swallowed errors, missing user feedback, unjustified fallbacks. |
 | **Test Analyzer** | When test files are changed, or when new functionality lacks corresponding tests | Behavioral coverage gaps, brittle tests, missing edge cases, tests that prove nothing. |
 | **Type Design Analyzer** | When new types/interfaces are introduced or existing types are modified | Encapsulation, invariant expression, invariant enforcement. Rates each type 1-10 on four axes. |
@@ -119,7 +114,6 @@ The Security Reviewer agent runs a systematic audit against two layers: universa
 - `src/stripe/**`, `src/web/routes/billing.ts` — payment flows
 - `src/github/webhooks.ts`, `src/web/routes/webhooks.ts` — webhook verification
 - `src/db/**` — database access, schema changes
-- `src/upload/**` — file upload validation
 - Any file containing `validateRepoOwnership`, `runQuery`, `encryptProperty`, `verifyWebhookSignature`
 
 **Output format:** Each finding must include:
@@ -161,7 +155,7 @@ Trigger Phase 3 when ANY of these are true:
 - Changes touch **tenant isolation, query construction, or data access patterns**
 - Changes touch **billing, subscription management, or payment flows**
 - Changes modify **webhook verification or signature checking**
-- Regression risk from Phase 1 is **HIGH**
+- The Phase 1 blast radius marks the change as **HIGH** risk
 - You are not confident about a specific change's correctness
 
 If none of these triggers are met, **skip Phase 3** and proceed to Phase 4.