sync(skills): mirror 61969cbc and pin @pathmode/mcp-server@1.35.1

.mcp.json

@@ -2,7 +2,7 @@
     "mcpServers": {
         "pathmode": {
             "command": "npx",
-            "args": ["-y", "@pathmode/mcp-server@1.35.0"],
+            "args": ["-y", "@pathmode/mcp-server@1.35.1"],
             "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.0`, 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.35.1`, 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

@@ -11,7 +11,7 @@ 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.
 
-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.
+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.