sync(skills): mirror c7efeee0 and pin @pathmode/mcp-server@1.41.3

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "pathmode",
   "displayName": "Pathmode",
-  "version": "0.1.49",
+  "version": "0.1.50",
   "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.41.2"],
+            "args": ["-y", "@pathmode/mcp-server@1.41.3"],
             "env": {
                 "PATHMODE_API_KEY": "${user_config.api_key}"
             }

README.md

@@ -72,7 +72,7 @@ For workspace API access without a local intent, you can still create an API key
 
 ## What's bundled
 
-**MCP server** — `@pathmode/mcp-server@1.41.2`, 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.41.3`, 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 192 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/implement-intent/SKILL.md

@@ -5,6 +5,8 @@ description: Implement the repository's active intent only after running its det
 
 <what-to-do>
 
+In connected mode, before forming a proposal or implementation plan, call `list_intents` without a status filter. Establish the product from the repository binding or the user; ask if it is ambiguous. Look for relevant earlier decisions on that same product in intents that are **authorized, shipped, or verified**. Authorization is separate from lifecycle status: an authorized intent can still be draft. Read applicable decisions, their rationale, and reopen triggers; use `get_intent` when the list lacks the needed detail. In the new intent's existing `decisions`, record a `reason` naming the full prior intent ID and full prior decision ID (copy IDs exactly; never abbreviate), or the exact choice if no decision ID is present, its reopen trigger (or that none is recorded), and what it changes about this proposal. Do not claim reuse without an applicable source read. If a reopen trigger applies or the earlier decision conflicts with the request, surface it for a new product judgment. Earlier authorization never authorizes the new intent or changes to the earlier one. This discovery step is connected mode only; keyless mode has no workspace decision history.
+
 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, 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. If you can run a background command, start `npx @pathmode/mcp-server@latest watch-review` in the background, with `--build` if the person asked you to implement the change or `--no-build` if they asked only for a proposal, and end the turn: it prints one line when the review needs you, and the line says what to do. Restart it without either flag after applying answers. If the person changes their mind about building, for example "hold off", leave the listener running and run it once more with `--build --declare` or `--no-build --declare`: that records the change for this review and exits, and the running listener still reports their answers and verdict. After an authorization, build only once `get_agent_prompt` with `mode: execute` succeeds; if it refuses as not ready, show the person the blockers it names and do not implement. An authorization does not accept failed execution checks. Otherwise 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.
@@ -50,6 +52,6 @@ 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.
+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. For `outcomes`, copy the complete `{id, text, ...}` object from `get_intent` into `expectedOldValue`, and change only the intended fields in `proposedValue`; preserve the outcome ID, priority and measurement. Do not pass a bare string or the whole outcomes array. 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.