@pharaoh-so/mcp 0.3.44 → 0.3.46

package/commands/review.md

@@ -26,14 +26,20 @@ Before merging any branch. Before opening any PR. When reviewing changes that to
    git log --oneline -1                   # latest commit
    ```
 
-2. Determine the base (where this branch diverged from the branch it merges into):
+2. Determine the base (where this branch diverged from the branch it merges into). The target is the first of these that resolves:
    ```bash
-   DEFAULT=$(git symbolic-ref --short refs/remotes/origin/HEAD)   # the default branch, e.g. origin/main
-   BASE=$(git merge-base HEAD "$DEFAULT")                         # use the PR's target branch if it isn't the default
+   TARGET=$(gh pr view --json baseRefName --jq '"origin/" + .baseRefName' 2>/dev/null)   # the open PR's target branch
+   [ -n "$TARGET" ] || TARGET=$(git symbolic-ref -q --short refs/remotes/origin/HEAD)    # the default branch, set by git clone
+   [ -n "$TARGET" ] || for b in origin/main origin/master main master; do
+     git rev-parse -q --verify "$b" >/dev/null && TARGET=$b && break
+   done
+   BASE=$(git merge-base HEAD "$TARGET") && echo "base: $BASE"
    ```
+   If no base comes out, stop and ask which branch this merges into. An empty base makes every diff below come out empty, and the review would report no changes. If your shell doesn't keep variables between commands, set `BASE` to the printed commit at the start of each one.
 
 3. Collect the full changeset from the base:
    ```bash
+   : "${BASE:?no base: ask which branch this merges into}"   # stops here rather than diff HEAD against itself
    git diff --name-only "$BASE"...HEAD   # all changed files
    git diff --stat "$BASE"...HEAD        # summary stats
    git log --oneline "$BASE"..HEAD       # all commits on this branch
@@ -68,7 +74,7 @@ Pharaoh's graph maps the default branch, so it shows what the change lands on: c
 
 ### Without Pharaoh (graceful fallback)
 
-If Pharaoh isn't connected, or doesn't map this repo, build the same picture by hand:
+If Pharaoh isn't connected, or doesn't map this repo, build the same picture by hand. When Pharaoh is connected but doesn't map the repo, tell the user once that mapping it makes this review architecture-aware, with the install link from `pharaoh_account`, then carry on:
 1. Read the top-level layout and the manifest files (package.json, pyproject.toml, go.mod, Cargo.toml) to find the module boundaries
 2. For each changed exported function or file, search for its callers to estimate the blast radius
 3. Read the entry points the change can reach: routes, CLI commands, jobs, event handlers
@@ -113,7 +119,7 @@ The Security Reviewer agent runs a systematic audit against two layers: universa
 - **Logging & monitoring:** Sensitive data in logs, missing audit trails for privileged operations
 
 **Layer 2 — The project's own security rules:**
-Take them from the rules collected in Phase 1 (`CLAUDE.md`, `AGENTS.md`, `SECURITY.md`, `docs/VISION.md`) and check each one against the diff by name. Rules like "every query is scoped to the caller's tenant", "tokens are stored hashed" and "webhooks verify their signature" are what this layer exists for. If the project states none, work out its threat model from the code: who the users and tenants are, where secrets live, which inputs are untrusted.
+Take them from the project's rules collected in Phase 1 and check each one against the diff by name. Rules like "every query is scoped to the caller's tenant", "tokens are stored hashed" and "webhooks verify their signature" are what this layer exists for. If the project states none, work out its threat model from the code: who the users and tenants are, where secrets live, which inputs are untrusted.
 
 **Detection triggers (dispatch when the change touches any of these):**
 - Authentication, sessions, tokens, permissions, and the middleware that guards routes
@@ -124,7 +130,7 @@ Take them from the rules collected in Phase 1 (`CLAUDE.md`, `AGENTS.md`, `SECURI
 - File paths, uploads, shell commands or URLs built from user input
 - Anything the project's rules call security-sensitive
 
-With Pharaoh, find these structurally: `get_module_context` on a touched module lists its endpoints, database tables and environment variables, and `get_blast_radius` shows the endpoints, jobs and database operations a changed function reaches. A change that reaches an endpoint, a table or a secret is security-sensitive. Without Pharaoh, match on file paths and names (auth, session, token, crypto, middleware, webhook, billing, payment, migration).
+Always match on file paths and names (auth, session, token, crypto, middleware, webhook, billing, payment, migration), and classify files that are new on this branch from the diff itself. With Pharaoh, also find these structurally: `get_module_context` on a touched module lists its endpoints, database tables and environment variables, and `get_blast_radius` shows the endpoints, jobs and database operations a changed function reaches. A change that reaches an endpoint, a table or a secret is security-sensitive. Pharaoh's graph is the default branch, so it sees what existing code a change reaches, never the files the branch adds.
 
 **Output format:** Each finding must include:
 1. Vulnerability class (e.g., "SQL Injection", "Missing Authorization Check")
@@ -251,7 +257,7 @@ If none of these triggers are met, **skip Phase 3** and proceed to Phase 4.
 ### Auto-block triggers (any of these = BLOCK)
 
 - Any CRITICAL security finding (injection, broken access control, tenant isolation violation, secret exposure)
-- Unreachable exports (new public code with zero callers)
+- Unreachable exports in an application (new public code that nothing calls). In a library, exports are the public API: check each new one is documented or tested instead. Without graph reachability data, a search can't prove nothing calls it: raise it under SHIP WITH CHANGES, not BLOCK
 - New circular dependencies between modules
 - HIGH regression risk without corresponding test coverage
 - **A MUST-bullet in `docs/VISION.md` is violated by this change** (without VISION.md being updated in the same PR with user approval)
@@ -270,7 +276,7 @@ If none of these triggers are met, **skip Phase 3** and proceed to Phase 4.
 ### SHIP triggers
 
 - No CRITICAL or confirmed IMPORTANT findings
-- All new exports are reachable
+- All new exports are reachable (applications) or documented or tested (libraries)
 - Regression risk is LOW or MEDIUM with adequate test coverage
 - Spec alignment is clean or intentionally divergent with documentation
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@pharaoh-so/mcp",
   "mcpName": "so.pharaoh/pharaoh",
-  "version": "0.3.44",
+  "version": "0.3.46",
   "description": "MCP proxy for Pharaoh — maps codebases into queryable knowledge graphs for AI agents. Enables Claude Code in headless environments (VPS, SSH, CI) via device flow auth.",
   "type": "module",
   "main": "dist/index.js",

package/skills/review/SKILL.md

@@ -2,7 +2,7 @@
 name: review
 prompt-name: review-with-pharaoh
 description: "The definitive code review, for any codebase. Five-phase workflow: git context detection (worktree, branch, base, changed files), Pharaoh recon (architecture map, module context, blast radius in one call, with a fallback when the repo isn't mapped), parallel specialized agent dispatch (code quality, security against the project's own rules, error handling, test coverage, type design), adversarial review for security-sensitive changes, and a final synthesized verdict of SHIP / SHIP WITH CHANGES / BLOCK. Architecture-aware wherever Pharaoh maps the repo, always branch-aware."
-version: 0.4.0
+version: 0.4.2
 homepage: https://pharaoh.so
 user-invocable: true
 metadata: {"emoji": "☥", "tags": ["code-review", "pull-request", "architecture", "pharaoh", "multi-agent", "adversarial-review", "regression-risk", "spec-alignment"]}
@@ -32,14 +32,20 @@ Before merging any branch. Before opening any PR. When reviewing changes that to
    git log --oneline -1                   # latest commit
    ```
 
-2. Determine the base (where this branch diverged from the branch it merges into):
+2. Determine the base (where this branch diverged from the branch it merges into). The target is the first of these that resolves:
    ```bash
-   DEFAULT=$(git symbolic-ref --short refs/remotes/origin/HEAD)   # the default branch, e.g. origin/main
-   BASE=$(git merge-base HEAD "$DEFAULT")                         # use the PR's target branch if it isn't the default
+   TARGET=$(gh pr view --json baseRefName --jq '"origin/" + .baseRefName' 2>/dev/null)   # the open PR's target branch
+   [ -n "$TARGET" ] || TARGET=$(git symbolic-ref -q --short refs/remotes/origin/HEAD)    # the default branch, set by git clone
+   [ -n "$TARGET" ] || for b in origin/main origin/master main master; do
+     git rev-parse -q --verify "$b" >/dev/null && TARGET=$b && break
+   done
+   BASE=$(git merge-base HEAD "$TARGET") && echo "base: $BASE"
    ```
+   If no base comes out, stop and ask which branch this merges into. An empty base makes every diff below come out empty, and the review would report no changes. If your shell doesn't keep variables between commands, set `BASE` to the printed commit at the start of each one.
 
 3. Collect the full changeset from the base:
    ```bash
+   : "${BASE:?no base: ask which branch this merges into}"   # stops here rather than diff HEAD against itself
    git diff --name-only "$BASE"...HEAD   # all changed files
    git diff --stat "$BASE"...HEAD        # summary stats
    git log --oneline "$BASE"..HEAD       # all commits on this branch
@@ -74,7 +80,7 @@ Pharaoh's graph maps the default branch, so it shows what the change lands on: c
 
 ### Without Pharaoh (graceful fallback)
 
-If Pharaoh isn't connected, or doesn't map this repo, build the same picture by hand:
+If Pharaoh isn't connected, or doesn't map this repo, build the same picture by hand. When Pharaoh is connected but doesn't map the repo, tell the user once that mapping it makes this review architecture-aware, with the install link from `pharaoh_account`, then carry on:
 1. Read the top-level layout and the manifest files (package.json, pyproject.toml, go.mod, Cargo.toml) to find the module boundaries
 2. For each changed exported function or file, search for its callers to estimate the blast radius
 3. Read the entry points the change can reach: routes, CLI commands, jobs, event handlers
@@ -119,7 +125,7 @@ The Security Reviewer agent runs a systematic audit against two layers: universa
 - **Logging & monitoring:** Sensitive data in logs, missing audit trails for privileged operations
 
 **Layer 2 — The project's own security rules:**
-Take them from the rules collected in Phase 1 (`CLAUDE.md`, `AGENTS.md`, `SECURITY.md`, `docs/VISION.md`) and check each one against the diff by name. Rules like "every query is scoped to the caller's tenant", "tokens are stored hashed" and "webhooks verify their signature" are what this layer exists for. If the project states none, work out its threat model from the code: who the users and tenants are, where secrets live, which inputs are untrusted.
+Take them from the project's rules collected in Phase 1 and check each one against the diff by name. Rules like "every query is scoped to the caller's tenant", "tokens are stored hashed" and "webhooks verify their signature" are what this layer exists for. If the project states none, work out its threat model from the code: who the users and tenants are, where secrets live, which inputs are untrusted.
 
 **Detection triggers (dispatch when the change touches any of these):**
 - Authentication, sessions, tokens, permissions, and the middleware that guards routes
@@ -130,7 +136,7 @@ Take them from the rules collected in Phase 1 (`CLAUDE.md`, `AGENTS.md`, `SECURI
 - File paths, uploads, shell commands or URLs built from user input
 - Anything the project's rules call security-sensitive
 
-With Pharaoh, find these structurally: `get_module_context` on a touched module lists its endpoints, database tables and environment variables, and `get_blast_radius` shows the endpoints, jobs and database operations a changed function reaches. A change that reaches an endpoint, a table or a secret is security-sensitive. Without Pharaoh, match on file paths and names (auth, session, token, crypto, middleware, webhook, billing, payment, migration).
+Always match on file paths and names (auth, session, token, crypto, middleware, webhook, billing, payment, migration), and classify files that are new on this branch from the diff itself. With Pharaoh, also find these structurally: `get_module_context` on a touched module lists its endpoints, database tables and environment variables, and `get_blast_radius` shows the endpoints, jobs and database operations a changed function reaches. A change that reaches an endpoint, a table or a secret is security-sensitive. Pharaoh's graph is the default branch, so it sees what existing code a change reaches, never the files the branch adds.
 
 **Output format:** Each finding must include:
 1. Vulnerability class (e.g., "SQL Injection", "Missing Authorization Check")
@@ -257,7 +263,7 @@ If none of these triggers are met, **skip Phase 3** and proceed to Phase 4.
 ### Auto-block triggers (any of these = BLOCK)
 
 - Any CRITICAL security finding (injection, broken access control, tenant isolation violation, secret exposure)
-- Unreachable exports (new public code with zero callers)
+- Unreachable exports in an application (new public code that nothing calls). In a library, exports are the public API: check each new one is documented or tested instead. Without graph reachability data, a search can't prove nothing calls it: raise it under SHIP WITH CHANGES, not BLOCK
 - New circular dependencies between modules
 - HIGH regression risk without corresponding test coverage
 - **A MUST-bullet in `docs/VISION.md` is violated by this change** (without VISION.md being updated in the same PR with user approval)
@@ -276,7 +282,7 @@ If none of these triggers are met, **skip Phase 3** and proceed to Phase 4.
 ### SHIP triggers
 
 - No CRITICAL or confirmed IMPORTANT findings
-- All new exports are reachable
+- All new exports are reachable (applications) or documented or tested (libraries)
 - Regression risk is LOW or MEDIUM with adequate test coverage
 - Spec alignment is clean or intentionally divergent with documentation