@pathmode/mcp-server 1.30.0 → 1.31.1

package/dist/packages/mcp-server/src/push-spec.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"push-spec.d.ts","sourceRoot":"","sources":["file:///Users/jannelammi/code/Pathmode/packages/mcp-server/src/push-spec.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAIH;;6FAE6F;AAC7F,MAAM,WAAW,eAAe;IAC5B,EAAE,EAAE,MAAM,CAAC;IACX,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,gBAAgB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACjC,MAAM,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,aAAa,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC9B;;oFAEgF;IAChF,iBAAiB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;CACrC;AAED,MAAM,WAAW,UAAU;IACvB,YAAY,CAAC,KAAK,EAAE,GAAG,GAAG,OAAO,CAAC,eAAe,CAAC,CAAC;IACnD,sEAAsE;IACtE,SAAS,CAAC,CAAC,EAAE,EAAE,MAAM,GAAG,OAAO,CAAC,eAAe,CAAC,CAAC;IACjD,kFAAkF;IAClF,QAAQ,CAAC,WAAW,CAAC,EAAE,MAAM,CAAC;IAC9B,sBAAsB,CAAC,CAAC,QAAQ,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC;QAAE,aAAa,CAAC,EAAE;YAAE,MAAM,CAAC,EAAE,MAAM,CAAA;SAAE,CAAA;KAAE,CAAC,CAAC;IAC/G,YAAY,CAAC,EAAE,EAAE,MAAM,EAAE,KAAK,EAAE,GAAG,GAAG,OAAO,CAAC,eAAe,CAAC,CAAC;IAC/D,cAAc,CAAC,QAAQ,EAAE,MAAM,EAAE,KAAK,EAAE,GAAG,GAAG,OAAO,CAAC,OAAO,CAAC,CAAC;IAC/D,yBAAyB,CAAC,QAAQ,EAAE,MAAM,EAAE,KAAK,EAAE,GAAG,GAAG,OAAO,CAAC,OAAO,CAAC,CAAC;CAC7E;AAED;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,cAAc,CAAC,QAAQ,EAAE,MAAM,EAAE,WAAW,EAAE,MAAM,EAAE,OAAO,SAAI,GAAG,MAAM,CAUzF;AA0DD,MAAM,WAAW,aAAa;IAC1B,MAAM,EAAE,UAAU,CAAC;IACnB,iEAAiE;IACjE,EAAE,EAAE,MAAM,CAAC;IACX,kGAAkG;IAClG,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B;;;8EAG0E;IAC1E,sBAAsB,CAAC,EAAE,MAAM,CAAC;IAChC,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;IACjC,SAAS,CAAC,EAAE;QAAE,MAAM,EAAE,MAAM,CAAC;QAAC,MAAM,EAAE,MAAM,CAAC;QAAC,QAAQ,CAAC,EAAE,MAAM,CAAA;KAAE,EAAE,CAAC;IACpE,qBAAqB,CAAC,EAAE,MAAM,CAAC;IAC/B;0FACsF;IACtF,aAAa,CAAC,EAAE;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,oBAAoB,EAAE,MAAM,CAAA;KAAE,CAAC;IAC7D,sFAAsF;IACtF,iBAAiB,EAAE,CAAC,MAAM,EAAE;QAAE,WAAW,EAAE,MAAM,CAAC;QAAC,WAAW,CAAC,EAAE,MAAM,CAAC;QAAC,SAAS,EAAE,MAAM,CAAC;QAAC,MAAM,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,aAAa,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,iBAAiB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;KAAE,KAAK,IAAI,CAAC;CACnM;AAED,MAAM,MAAM,cAAc,GACpB;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,WAAW,EAAE,MAAM,CAAC;IAAC,WAAW,CAAC,EAAE,MAAM,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,YAAY,EAAE,MAAM,EAAE,CAAA;CAAE,GAClG;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,KAAK,EAAE,MAAM,CAAC;IAAC,IAAI,CAAC,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,EAAE;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAC;QAAC,SAAS,CAAC,EAAE,OAAO,CAAA;KAAE,EAAE,CAAA;CAAE,CAAC;AAElH,wBAAsB,QAAQ,CAAC,KAAK,EAAE,aAAa,GAAG,OAAO,CAAC,cAAc,CAAC,CA0L5E"}
+{"version":3,"file":"push-spec.d.ts","sourceRoot":"","sources":["file:///Users/jannelammi/code/Pathmode/packages/mcp-server/src/push-spec.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAIH;;6FAE6F;AAC7F,MAAM,WAAW,eAAe;IAC5B,uBAAuB,CAAC,EAAE,MAAM,CAAC;IACjC,2BAA2B,CAAC,EAAE,MAAM,CAAC;IACrC,2BAA2B,CAAC,EAAE,MAAM,CAAC;IACrC,EAAE,EAAE,MAAM,CAAC;IACX,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,gBAAgB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACjC,MAAM,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,aAAa,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC9B;;oFAEgF;IAChF,iBAAiB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;CACrC;AAED,MAAM,WAAW,UAAU;IACvB,YAAY,CAAC,IAAI,OAAO,CAAC;QAAE,YAAY,CAAC,EAAE;YAAE,gBAAgB,CAAC,EAAE,MAAM,CAAA;SAAE,CAAA;KAAE,CAAC,CAAC;IAC3E,YAAY,CAAC,KAAK,EAAE,GAAG,GAAG,OAAO,CAAC,eAAe,CAAC,CAAC;IACnD,sEAAsE;IACtE,SAAS,CAAC,CAAC,EAAE,EAAE,MAAM,GAAG,OAAO,CAAC,eAAe,CAAC,CAAC;IACjD,kFAAkF;IAClF,QAAQ,CAAC,WAAW,CAAC,EAAE,MAAM,CAAC;IAC9B,sBAAsB,CAAC,CAAC,QAAQ,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC;QAAE,aAAa,CAAC,EAAE;YAAE,MAAM,CAAC,EAAE,MAAM,CAAC;YAAC,WAAW,CAAC,EAAE,MAAM,CAAC;YAAC,oBAAoB,CAAC,EAAE,MAAM,CAAC;YAAC,uBAAuB,CAAC,EAAE,MAAM,CAAA;SAAE,CAAA;KAAE,CAAC,CAAC;IACtM,YAAY,CAAC,EAAE,EAAE,MAAM,EAAE,KAAK,EAAE,GAAG,GAAG,OAAO,CAAC,eAAe,CAAC,CAAC;IAC/D,cAAc,CAAC,QAAQ,EAAE,MAAM,EAAE,KAAK,EAAE,GAAG,GAAG,OAAO,CAAC,OAAO,CAAC,CAAC;IAC/D,yBAAyB,CAAC,QAAQ,EAAE,MAAM,EAAE,KAAK,EAAE,GAAG,GAAG,OAAO,CAAC,OAAO,CAAC,CAAC;CAC7E;AAED;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,cAAc,CAAC,QAAQ,EAAE,MAAM,EAAE,WAAW,EAAE,MAAM,EAAE,OAAO,SAAI,GAAG,MAAM,CAUzF;AA0DD,MAAM,WAAW,aAAa;IAC1B,MAAM,EAAE,UAAU,CAAC;IACnB,iEAAiE;IACjE,EAAE,EAAE,MAAM,CAAC;IACX,kGAAkG;IAClG,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B;;;8EAG0E;IAC1E,sBAAsB,CAAC,EAAE,MAAM,CAAC;IAChC,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;IACjC,SAAS,CAAC,EAAE;QAAE,MAAM,EAAE,MAAM,CAAC;QAAC,MAAM,EAAE,MAAM,CAAC;QAAC,QAAQ,CAAC,EAAE,MAAM,CAAA;KAAE,EAAE,CAAC;IACpE,qBAAqB,CAAC,EAAE,MAAM,CAAC;IAC/B;0FACsF;IACtF,aAAa,CAAC,EAAE;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,oBAAoB,EAAE,MAAM,CAAA;KAAE,CAAC;IAC7D,sFAAsF;IACtF,iBAAiB,EAAE,CAAC,MAAM,EAAE;QAAE,eAAe,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;QAAC,WAAW,EAAE,MAAM,CAAC;QAAC,WAAW,CAAC,EAAE,MAAM,CAAC;QAAC,SAAS,EAAE,MAAM,CAAC;QAAC,MAAM,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,aAAa,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;QAAC,iBAAiB,CAAC,EAAE,MAAM,GAAG,IAAI,CAAA;KAAE,KAAK,IAAI,CAAC;CAC9O;AAED,MAAM,MAAM,cAAc,GACpB;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,2BAA2B,CAAC,EAAE,MAAM,CAAC;IAAC,2BAA2B,CAAC,EAAE,MAAM,CAAC;IAAC,WAAW,EAAE,MAAM,CAAC;IAAC,WAAW,CAAC,EAAE,MAAM,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,YAAY,EAAE,MAAM,EAAE,CAAA;CAAE,GAC9K;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,KAAK,EAAE,MAAM,CAAC;IAAC,IAAI,CAAC,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,EAAE;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAC;QAAC,SAAS,CAAC,EAAE,OAAO,CAAA;KAAE,EAAE,CAAA;CAAE,CAAC;AAElH,wBAAsB,QAAQ,CAAC,KAAK,EAAE,aAAa,GAAG,OAAO,CAAC,cAAc,CAAC,CAkN5E"}

package/dist/packages/mcp-server/src/repo-bound-preflight.d.ts

@@ -0,0 +1,18 @@
+/**
+ * Why a repository-bound preflight must refuse rather than grade the workspace's current intent.
+ *
+ * Returns the refusal text, or undefined when the caller may proceed. Split out from the handler
+ * so the rule is testable without standing up a server.
+ *
+ * Both absences refuse, for different reasons. `rootsInspected` false means we do not know which
+ * repository we are in, so any answer is a guess. `rootsInspected` true means we do know, and we
+ * know it has no intent.md — which is a fact about this repository, not licence to answer about a
+ * different one. The second case used to fall through to the workspace's heuristic "current"
+ * intent; on 2026-09-19 that graded a cancellation ticket in one repository against a demo
+ * shoe-return intent from another. An explicit intentId is always honoured: the caller chose.
+ */
+export declare function repoBoundPreflightRefusal(resolution: {
+    kind: 'absent';
+    rootsInspected: boolean;
+}, intentId?: string): string | undefined;
+//# sourceMappingURL=repo-bound-preflight.d.ts.map

package/dist/packages/mcp-server/src/repo-bound-preflight.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"repo-bound-preflight.d.ts","sourceRoot":"","sources":["file:///Users/jannelammi/code/Pathmode/packages/mcp-server/src/repo-bound-preflight.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AACH,wBAAgB,yBAAyB,CACrC,UAAU,EAAE;IAAE,IAAI,EAAE,QAAQ,CAAC;IAAC,cAAc,EAAE,OAAO,CAAA;CAAE,EACvD,QAAQ,CAAC,EAAE,MAAM,GAClB,MAAM,GAAG,SAAS,CAWpB"}

package/manifest.json

@@ -2,7 +2,7 @@
   "manifest_version": "0.3",
   "name": "pathmode",
   "display_name": "Pathmode",
-  "version": "1.30.0",
+  "version": "1.31.1",
   "description": "Deterministic preflight for the intent you hand to a coding agent: six calibrated gates, the exact blockers named, no model call, no key needed.",
   "long_description": "Pathmode MCP Server runs a deterministic preflight before your coding agent builds: check_intent_readiness scores an intent spec against six calibrated gates (title, objective, outcomes, constraints, edge cases, verification) and names the exact blockers, with no model call and no account. Keyless local mode works out of the box; specs live in intent.md in your repo, plain markdown you own, and skills for drafting, pressure-testing, and handing off intent ride along. Connect a Pathmode workspace with an API key to sync intent and evidence across a team, analyze dependency graphs, and verify pull requests against the outcomes you agreed to.",
   "author": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pathmode/mcp-server",
-  "version": "1.30.0",
+  "version": "1.31.1",
   "publishConfig": {
     "access": "public"
   },
@@ -19,6 +19,7 @@
   ],
   "scripts": {
     "build": "rm -rf dist && ncc build src/index.ts -o dist",
+    "typecheck": "tsc --noEmit",
     "dev": "ts-node src/index.ts",
     "prepublishOnly": "npm run build"
   },
@@ -48,7 +49,7 @@
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.12.1",
     "gray-matter": "^4.0.3",
-    "zod": "^3.24.0"
+    "zod": "^4.5.4"
   },
   "overrides": {
     "@hono/node-server": "^1.19.17",

package/skills/compile-intent/SKILL.md

@@ -11,7 +11,9 @@ For each question you ask, propose your best-guess answer based on the conversat
 
 Before the spec is finished, gather implementation context. You are already sitting in the repo, so read it: which files and modules this change lands in, what already exists there, what it would touch, and how it could be verified. Pass it to `intent_save` as `implementationContext` — in both modes. A brand-new spec has no intent id yet, so there is nothing to address a separate call to; `intent_save` carries the context through as part of the save. Use `record_implementation_context` only to update the context on an intent that already exists. It is free text, sub-headings welcome, and it is advisory — it never changes the readiness verdict. Its job is to stop the implementing agent from rediscovering the codebase from scratch, and to catch the case where the thing being specified half-exists already.
 
-When the spec is ready, call the `intent_save` MCP tool to write `intent.md` to the project root.
+Save the proposal before pretending its open choices are requirements. Use the typed `productChoices` input on `intent_save` for consequential unanswered behavior; supply only proposals, never state, human actors, timestamps, or source-settlement flags. Existing choice IDs are stable; do not replace a question by recycling its ID. The server preserves existing choices. A failed capability check means this installed path is unavailable, not that the question was recorded.
+
+For a new choice-bearing proposal, call `intent_save(localDraft: true)` to write `intent.md` locally, then use the existing repository-adoption flow for team review. Adoption preserves the open choices and establishes repository ownership. Ordinary v1 creates remain cloud-owned and reject choice proposals. Do not detach an already connected file with `localDraft`; add proposals through its normal connected save once it has repository authority. After successful adoption, call `attach_original_request`, copying the original request verbatim, and invite the reviewer to the adopted proposal. Stop while its choices remain unresolved or its exact revision lacks human authorization. Answers create corrections for the repository agent to apply; application and authorization are separate steps.
 
 </what-to-do>
 

package/skills/implement-intent/SKILL.md

@@ -5,6 +5,15 @@ description: Implement the repository's active intent only after running its det
 
 <what-to-do>
 
+If the repository has no `intent.md`, stop implementation and propose an intent for the user's actual request. Never substitute the workspace's most recent intent. Use `intent_save(localDraft: true)` with open `productChoices` for consequential behavior the request leaves undecided; each needs a recommendation, reason, alternative, trade-off, reopen trigger, and contingent claims. Do not copy those claims into required outcomes before a reviewer answers. If the installed server does not support this input, report the version limitation rather than claiming the choices were saved.
+
+For team review of a new local draft, use the existing Pathmode repository-adoption flow and its `adopt pm_adopt_…` command. Adoption carries the open choices and establishes repository ownership; an API key or a choice-bearing create does not. If adoption is unavailable, preserve the local draft and stop rather than create an unbound repository intent. After successful adoption, call `attach_original_request` with the verbatim request, then send the review link and stop at not ready. A terminal answer is not another person's judgment or workspace authorization. In keyless mode retain the source request alongside the intent and report the open choices; do not invent a cloud handoff.
+
+Before applying a repository choice request, use `get_intent` to refresh the current body and read the request. Call `intent_save` using the request's original `changeRequestId` and `baseRepoBodyRevision`. Do not include new choice proposals or unrelated body edits in that apply. Unchanged sibling answers may apply sequentially; a changed target or parent needs renewed human review. Refused applies are not permission to bypass the request. A requested deferral still waits for application and remains a readiness blocker afterward.
+
+After application, inspect the returned revision and stop for separate whole-revision authorization. In a fresh implementation session, call `get_intent` and verify that `authorization` is authorized and `authorizedRepoBodyRevision` equals `repoBodyRevision`, then use the existing readiness/prompt path below. A change-request read receipt is not proof that this authorized revision was read.
+
+
 Read `intent.md` from the project root first. It is the repository-bound authority. Call `check_intent_readiness` before changing product code: with no arguments for that file, or with `intentId` only when the user explicitly selected a cloud-only intent.
 
 If Preflight has unresolved blockers, show its exact verdict and work through the `preflight` repair loop one targeted question at a time. Do not silently begin implementation from a failing spec.
@@ -17,7 +26,7 @@ The user may explicitly accept named blockers and ask you to proceed. That is **
 
 Re-run Preflight afterward and show the still-failing verdict. Never turn accepted risk into a green check. The acceptance authorizes only this implementation conversation; a later agent must ask again unless it has fresh human authorization for the exact revision.
 
-In connected mode, a save changes the repository-body revision. Stop until a signed-in product owner authorizes that exact revision. Then call `get_agent_prompt`: use `mode: execute` when Preflight passes, or `mode: draft` when the user explicitly accepted still-visible blockers. Stop on an open change request or a pending, rejected, or stale authorization banner. Fetch `get_constitution` before implementation.
+In connected mode, a save changes the repository-body revision. Stop until a signed-in product manager authorizes that exact revision. Then call `get_agent_prompt`: use `mode: execute` when Preflight passes, or `mode: draft` when the user explicitly accepted still-visible blockers. Stop on an open change request or a pending, rejected, or stale authorization banner. Fetch `get_constitution` before implementation.
 
 In keyless mode, do not call `get_agent_prompt`, `get_constitution`, or other cloud-only tools. Use `intent.md`, the repository instructions, and the codebase itself as the implementation context.
 

package/skills/preflight/SKILL.md

@@ -5,9 +5,9 @@ description: Run the deterministic readiness check on an intent spec before an a
 
 <what-to-do>
 
-Call the `check_intent_readiness` MCP tool (Pathmode). With no arguments it resolves `intent.md` from the MCP client's declared workspace roots or the server launch directory. Connected mode falls back to the workspace current intent only when declared roots are known to contain no repo-bound file; if the repository cannot be identified, it refuses to guess and asks for `intentId` or an inline `spec`. Pass `spec` inline to preflight a draft before saving it, or `intentId` when the user deliberately selects a different saved intent.
+Call the `check_intent_readiness` MCP tool (Pathmode). With no arguments it resolves `intent.md` from the MCP client's declared workspace roots or the server launch directory. If that repository has no `intent.md`, or the repository cannot be identified, it refuses instead of substituting a workspace or local "current" intent. Pass `spec` inline to preflight a draft before saving it, or `intentId` when the user deliberately selects a specific saved intent.
 
-In connected mode, when the repo-bound file carries a cloud id, check for PM judgment before implementation: call `list_intent_change_requests` with that id. For every open request, call `get_intent_change_request`, apply the requested field/item change deliberately to `intent.md`, and call `intent_save` with the request's exact `changeRequestId` and `baseRepoBodyRevision`. If the request is unworkable, call `reject_intent_change_request` with a concrete reason instead of pretending it was applied. After an applied request, re-run the readiness check, report that the new repository revision is pending human authorization, and STOP. Do not begin implementation until a later `get_agent_prompt` confirms that the exact current revision is authorized by a signed-in product owner.
+In connected mode, when the repo-bound file carries a cloud id, check for PM judgment before implementation: call `list_intent_change_requests` with that id. For every open request, call `get_intent_change_request`, apply the requested field/item change deliberately to `intent.md`, and call `intent_save` with the request's exact `changeRequestId` and `baseRepoBodyRevision`. If the request is unworkable, call `reject_intent_change_request` with a concrete reason instead of pretending it was applied. After an applied request, re-run the readiness check, report that the new repository revision is pending human authorization, and STOP. Do not begin implementation until a later `get_agent_prompt` confirms that the exact current revision is authorized by a signed-in product manager.
 
 Show the user the verdict block exactly as returned — the blocker strings are the calibrated gate output, do not paraphrase them.
 
@@ -34,7 +34,7 @@ The gate is pure functions over the spec text: no model call, no network. Re-run
 
 Every `intent_save` also stamps the verdict into the file's frontmatter as `readiness:` ("passed 6/6", or "failed N/6" with the blocking gates named), so anyone reading intent.md — human or agent — sees the gate state without re-running anything. A failing verdict never blocks the save; the gate reports, the user decides.
 
-A saved intent can also carry product choices its brief proposed and no human has resolved. Those are not one of the six checks: the verdict reports them separately ("⛔ Not ready to hand to an agent: N product choices still unresolved"), the frontmatter appends "— blocked by N unresolved product choice(s)", and `get_agent_prompt` in execute mode says do not implement. A recommendation attached to an open choice is an assumption. Ask the product owner to resolve or explicitly exclude it in Pathmode; do not resolve it from the repository.
+A saved intent can also carry product choices its brief proposed and no human has resolved. Those are not one of the six checks: the verdict reports them separately ("⛔ Not ready to hand to an agent: N product choices still unresolved"), the frontmatter appends "— blocked by N unresolved product choice(s)", and `get_agent_prompt` in execute mode says do not implement. A recommendation attached to an open choice is an assumption. Ask the product manager to resolve or explicitly exclude it in Pathmode; do not resolve it from the repository.
 
 ## Division of labor with the other skills
 

package/skills/review-against-intent/SKILL.md

@@ -5,9 +5,9 @@ description: Review code changes against the active intent's outcomes and constr
 
 <what-to-do>
 
-Load the active intent. Read `intent.md` from the project root first — the file is bound to this repository, which makes it the authority on what governs this diff. If `PATHMODE_API_KEY` is set and the file's frontmatter carries a cloud id, also fetch that intent's execution bundle (`get_agent_prompt` with the id) to pick up what the file cannot hold: open PM change requests, findings, handoff notes, and authorization state. Do not let `get_current_intent` choose the intent for you when a local file exists — "current" is a workspace heuristic, not a repo binding. Only with no local file at all, fall back to `get_current_intent`.
+Load the active intent from `intent.md` in the project root — the file is bound to this repository, which makes it the authority on what governs this diff. If `PATHMODE_API_KEY` is set and the file's frontmatter carries a cloud id, also fetch that intent's execution bundle (`get_agent_prompt` with the id) to pick up what the file cannot hold: open PM change requests, findings, handoff notes, and authorization state. Never let `get_current_intent` choose an intent for a repository review: "current" is a workspace heuristic, not a repo binding. If the repository has no `intent.md`, stop and ask for an explicit `intentId` or inline spec instead of guessing.
 
-If the execution bundle reports an open PM change request, or says the current repository revision is pending, rejected, or stale, stop before reviewing the diff as delivered work. Name the exact request/revision blocker and direct the agent through `preflight`: a requested spec change must be applied with request-bound `intent_save`, then a signed-in product owner must authorize that exact resulting revision. Never approve code against the superseded or unauthorized spec.
+If the execution bundle reports an open PM change request, or says the current repository revision is pending, rejected, or stale, stop before reviewing the diff as delivered work. Name the exact request/revision blocker and direct the agent through `preflight`: a requested spec change must be applied with request-bound `intent_save`, then a signed-in product manager must authorize that exact resulting revision. Never approve code against the superseded or unauthorized spec.
 
 Identify the changed files using git diff against the base branch (or staged changes if no base specified).
 
@@ -53,4 +53,4 @@ When the review finds gaps, the user often wants to record what's not yet done s
 
 </supporting-info>
 
-If the diff is right and the spec is wrong (the code satisfies what users need but contradicts an outcome, constraint, or edge case as written), do not approve the diff against the stale text and do not rewrite intent.md yourself. Record the finding with `record_implementation_finding` and propose the exact correction with `propose_spec_change`; a signed-in product owner accepts or rejects it, and only an accepted request may be applied. Say in the review which claim is contradicted and that a proposal is pending.
+If the diff is right and the spec is wrong (the code satisfies what users need but contradicts an outcome, constraint, or edge case as written), do not approve the diff against the stale text and do not rewrite intent.md yourself. Record the finding with `record_implementation_finding` and propose the exact correction with `propose_spec_change`; a signed-in product manager accepts or rejects it, and only an accepted request may be applied. Say in the review which claim is contradicted and that a proposal is pending.