Release 0.1.42: pin @pathmode/mcp-server 1.36.0, mirror 8113f707

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "pathmode",
   "displayName": "Pathmode",
-  "version": "0.1.41",
+  "version": "0.1.42",
   "description": "Run a deterministic preflight on your intent before an agent builds: /preflight scores six calibrated gates and names the exact blockers, no model call, no key. Pathmode also interrogates the intent behind a request (compile-intent), writes it to intent.md in your repo, and checks the code that comes back against the outcomes and constraints you agreed to. Free: uses the models you already have access to in Claude Code. Connect a Pathmode workspace to sync intent and evidence across a team.",
   "author": {
     "name": "Pathmode",

.mcp.json

@@ -2,7 +2,7 @@
     "mcpServers": {
         "pathmode": {
             "command": "npx",
-            "args": ["-y", "@pathmode/mcp-server@1.35.5"],
+            "args": ["-y", "@pathmode/mcp-server@1.36.0"],
             "env": {
                 "PATHMODE_API_KEY": "${user_config.api_key}"
             }

README.md

@@ -64,7 +64,7 @@ To sync with a Pathmode workspace (33 tools: evidence queries, revision-bound PM
 
 ## What's bundled
 
-**MCP server** — `@pathmode/mcp-server@1.35.5`, pinned so the plugin skills and server tool contract update together. Local mode with no key; cloud mode with one.
+**MCP server** — `@pathmode/mcp-server@1.36.0`, pinned so the plugin skills and server tool contract update together. Local mode with no key; cloud mode with one.
 
 **Check the gate yourself** — `node scripts/readiness-suite.mjs` runs the pinned server's preflight over 111 labelled field fixtures and a set of whole `intent.md` documents, and prints where it disagrees. Read [CALIBRATION.md](CALIBRATION.md) first: the field score is a regression baseline, not an accuracy claim.
 

skills/compile-intent/SKILL.md

@@ -13,7 +13,7 @@ Before the spec is finished, gather implementation context. You are already sitt
 
 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. Word each contingent outcome claim as an observable result (a state, a number, a visible element) before the first save, because a saved choice cannot be edited: accepting a choice adds its outcomes to the spec, and the preflight flags any it cannot read as measurable, since such an outcome counts against the outcomes check. If one is flagged, say so when you explain the choice; the answer can then carry a measurable outcome instead (`answer_product_choice` action `change` without a workspace, the reviewer's change with one). 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.
+For a new choice-bearing proposal, call `intent_save(localDraft: true)` to write `intent.md` locally, then run `npx @pathmode/mcp-server@latest adopt` in the repository and relay its link and code for browser approval. 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>
 
@@ -66,3 +66,5 @@ After compiling, these skills consume the spec:
 - `handoff-intent` — capture decisions and discoveries back to the spec at end of session
 
 </supporting-info>
+
+If adoption reports `AUTHORIZATION_PENDING`, preserve the draft and rerun the same command after the person approves.

skills/implement-intent/SKILL.md

@@ -7,7 +7,7 @@ description: Implement the repository's active intent only after running its det
 
 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. In keyless mode, the person's explicit answer to each choice is recorded with `answer_product_choice`, which adds the accepted claims itself; never write a choice's state or claims by hand. 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.
+For team review of a new local draft, run `npx @pathmode/mcp-server@latest adopt` in the repository and relay its link and code for browser approval. 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.
 
@@ -51,3 +51,5 @@ In connected mode, name the intent where the merge can find it: branch `intent/<
 ## When building contradicts the spec
 
 Record the contradiction with `record_implementation_finding` the moment you find it. If you can name the exact correction, call `propose_spec_change` with the same finding (`findingId`), the `baseRepoBodyRevision` you read, the target field and item, the value you observed and the value you propose, and the contradiction as the reason. That records a proposal for a signed-in person to accept or reject and stores your observation as unreviewed evidence; it does not change the spec. Keep implementing against the current authorized revision. Never call `intent_save` for your own proposal, and do not re-propose anything listed under "YOUR PENDING PROPOSALS" in the execution bundle.
+
+If adoption reports `AUTHORIZATION_PENDING`, preserve the draft and rerun the same command after the person approves.

skills/setup-pathmode-workflow/SKILL.md

@@ -5,6 +5,9 @@ description: Interview the user about their development workflow and capture the
 
 <what-to-do>
 
+For team review, run npx @pathmode/mcp-server@latest adopt in the repository. It prints a link and a code; give both to the person for browser approval. If it reports AUTHORIZATION_PENDING, stop and rerun the same command after approval. No spec is uploaded before approval. The browser-generated `adopt pm_adopt_...` command still works.
+
+
 Walk the user through the workflow questions below. Ask ONE question at a time. For each question, propose your best-guess answer based on what you can see in the repo (package.json scripts, CI config, README, existing PRs). The user accepts or corrects.
 
 Questions to cover (in order):