run402-mcp 4.37.0 → 4.37.1

package/README.md

@@ -409,7 +409,7 @@ git clone run402::<org_id>/<project_id> restored
 
 `gitvault snapshot` (`gitvault push` before design D5's rename) is the CAPTURE lane — the protocol deploy ref plus the HEAD target — because a dirty tree captures as a synthetic commit that sits on no branch. Your own branches and tags reach the vault through `git push origin <branch>`.
 
-**Allocating a vault currently gates the project's deploys**: the platform sets `gitvault_policy: required` at allocation, so from the moment a vault exists a deploy must present a vaulted capture at commit — `run402 deploy apply` produces one automatically on any machine holding the keystore (nothing to pass, no extra command), and every allocating path says so on stderr. Un-gate with `run402 gitvault policy grandfathered --reason "<why>"` (owner + step-up, audited, reversible with `run402 gitvault policy required`). Design D3 decouples allocation from the deploy gate — allocation will leave the policy unset until you choose — and ships with a later gateway change; the client already carries the ungated handling (a typed `next_actions` offer plus a standing `warnings[]` entry — never a block, never an interactive prompt). Vaulting your source is never gated on a deploy, either way. `run402 doctor` reports the policy, whether this machine can satisfy it, and where the keystore lives.
+**Allocating a vault does NOT gate the project's deploys** (design D3). `gitvault_policy` stays unset until you set it — a vault created by a first `git push` or `repos create` never silently changes how you deploy. A deploy against a vaulted, ungated project proceeds ungated and its result carries a typed `next_actions` entry offering `run402 gitvault policy required`; every later ungated deploy carries a `warnings[]` entry naming the drift, until the policy is set either way — never a block, never an interactive prompt. Once `gitvault_policy` is `required`, a deploy must present a vaulted capture at commit — `run402 deploy apply` produces one automatically on any machine holding the keystore; un-gate with `run402 gitvault policy grandfathered --reason "<why>"` (owner + step-up, audited, reversible with `run402 gitvault policy required`). Vaulting your source is never gated on a deploy, either way. `run402 doctor` reports the policy, whether this machine can satisfy it, and where the keystore lives.
 
 Before `snapshot` reports that anything landed, the client compares every finalization receipt against its local expected manifest and reads the admitted head back from storage — a 200 alone is never enough. Maintenance is `run402 gitvault compact` (checkpoint under a lease) and `run402 gitvault prune` (**two phases**: it plans locally, and submits only when handed both verifier receipts — one from this CLI, one from the independent `r402s-verify`; only the control-plane-signed completion says what was deleted).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "run402-mcp",
-  "version": "4.37.0",
+  "version": "4.37.1",
   "packageManager": "npm@11.19.0",
   "mcpName": "com.run402/mcp",
   "description": "MCP server for Run402 — full-stack backend infrastructure for AI agents: Postgres, auth, storage, serverless functions and atomic deploys. Paid with x402/MPP. Includes $0.03 image generation.",