feat(policy): add deployment readiness guards

.gitignore

@@ -13,3 +13,4 @@ docs/*.pdf
 .DS_Store
 __pycache__/
 *.pyc
+.codex/

apps/sint-mcp/src/downstream.ts

@@ -72,7 +72,7 @@ export class DownstreamManager {
     }
 
     const client = new Client(
-      { name: `sint-mcp-client-${name}`, version: "0.1.0" },
+      { name: `sint-mcp-client-${name}`, version: "0.1.1" },
       { capabilities: {} },
     );
 

apps/sint-mcp/src/server.ts

@@ -79,7 +79,7 @@ export class SintMCPServer {
 
     // Create MCP Server
     this.server = new Server(
-      { name: "sint-mcp", version: "0.1.0" },
+      { name: "sint-mcp", version: "0.1.1" },
       {
         capabilities: {
           tools: {},

docs/COMPETITIVE-LANDSCAPE.md

@@ -66,6 +66,38 @@
 
 **Where SINT fits:** AutoGPT agents controlling physical tools/robots need SINT's gateway between their decisions and physical actions.
 
+### Code-As-Policy Robot Agents
+
+**Examples:** Waddle-style systems that connect an API to a robot, take a
+natural-language task, write an editable robot control program, and grow a
+shared skill library from successful attempts.
+
+**What they do:** Move robot learning closer to the software-agent workflow:
+agents decompose goals, inspect camera feedback, write and revise code, call
+specialist action models, and execute physical primitives on real hardware.
+
+**Security posture:** Generated robot code and reusable skills create a new
+authority boundary. The agent may safely revise software, but a changed
+program, changed skill body, new primitive, or new workspace should not inherit
+prior approval to move hardware.
+
+**Where SINT fits:** SINT sits below the robot-agent platform as the runtime
+authorization and evidence layer. Generated programs stage through
+`engine://system2/plan`; approved execution routes through
+`engine://system2/execute`; reusable skills are content-bound through
+`engine://capsule/skill-library/register`; physical primitives still resolve to
+bridge resources such as ROS 2 actuation topics.
+
+**Gap SINT fills:** Content-digest binding for generated programs and skills,
+T2/T3 review before actuation, human-workspace escalation, primitive vocabulary
+constraints, and hash-chained receipts for every allow, deny, and escalation.
+
+Executable artifact:
+`packages/conformance-tests/fixtures/physical-ai/code-as-policy-skill-guard.v1.json`
+
+Runtime guard:
+`DefaultCodeAsPolicyGuard` in `@pshkv/gate-policy-gateway`
+
 ## SINT's Unique Position
 
 SINT is **not a competing agent protocol**. It is an **execution-governance layer** that sits between agent protocols and real execution surfaces. This positioning means:

docs/guides/code-as-policy-robot-agent-safety.md

@@ -0,0 +1,143 @@
+# Code-As-Policy Robot Agent Safety
+
+This guide captures the SINT integration pattern for robot agents that write,
+revise, and execute robot control programs.
+
+The motivating shape is Waddle-style robot agents: connect an API to a robot,
+prompt the agent, let it produce an editable policy program, and grow a shared
+skill library over time. SINT does not need to compete with that layer. It fits
+under it as the runtime authorization and evidence boundary between generated
+programs and physical actuation.
+
+## Fit
+
+Code-as-policy systems need at least three control points:
+
+- generated program staging before execution
+- reusable skill registration with content digests
+- physical primitive execution through robot middleware such as ROS 2
+
+SINT already has the required surfaces:
+
+- `engine://system2/plan` for staging and reviewing generated programs
+- `engine://capsule/skill-library/register` for content-bound skill promotion
+- `engine://system2/execute` for reviewed generated-program execution
+- ROS 2 resources such as
+  `ros2:///joint_trajectory_controller/follow_joint_trajectory` for actuator
+  commands
+- `EvidenceLedger` receipts binding the agent, program digest, skill digest,
+  primitive set, hardware profile, policy decision, and hash-chain pointers
+- `DefaultCodeAsPolicyGuard` in `@pshkv/gate-policy-gateway` for runtime
+  checks against generated-program digests, approved skill digests, primitive
+  allowlists, robot identity shape, and autonomous trial budgets
+
+## Run The Check
+
+```bash
+pnpm --filter @pshkv/conformance-tests exec vitest run src/code-as-policy-skill-guard-conformance.test.ts
+pnpm --filter @pshkv/gate-policy-gateway exec vitest run __tests__/code-as-policy-guard.test.ts
+```
+
+The fixture is:
+
+```text
+packages/conformance-tests/fixtures/physical-ai/code-as-policy-skill-guard.v1.json
+```
+
+## Boundary
+
+The fixture uses a vendor-neutral code-as-policy boundary:
+
+- generated robot program: `T1_prepare`
+- reusable skill registration: `T1_prepare`, content-bound
+- generated program execution: `T2_act`, reviewed
+- physical primitive actuation: `T2_act`, reviewed
+- human detected in the workspace: escalates to `T3_commit`
+- program body changed after approval: denied
+- skill or primitive vocabulary changed after approval: denied
+- autonomous data-collection and auto-research loops: bounded by trial budget
+
+## Receipt Shape
+
+Each receipt binds:
+
+- agent identity
+- robot identities
+- generated program reference and digest
+- reusable skill reference and digest
+- approved primitive set
+- hardware profile
+- workspace
+- resource and operation
+- assigned tier and decision
+- decision digest
+- evidence event hash and previous hash
+- timestamp
+
+The practical goal is to make robot-agent iteration auditable. A reviewer
+should be able to answer: which generated program or skill produced this
+trajectory, which physical limits applied, which robot executed it, and whether
+the program or skill changed after approval.
+
+## Integration Pattern
+
+1. The robot-agent platform emits a generated program artifact with a stable
+   digest.
+2. SINT records program staging as `engine://system2/plan`.
+3. Reusable skills are registered only with their digest, primitive set, and
+   hardware profile.
+4. Before execution, the agent requests `engine://system2/execute` with the
+   approved program digest and skill digests.
+5. Every physical primitive routes through the relevant bridge, commonly ROS 2.
+6. If a digest, primitive set, workspace, or physical constraint changes, the
+   previous approval no longer applies.
+
+This keeps generated code useful and editable while preventing silent mutation
+from becoming silent physical authority.
+
+## Runtime Guard
+
+Configure the gateway with an explicit primitive contract:
+
+```ts
+import { DefaultCodeAsPolicyGuard, PolicyGateway } from "@pshkv/gate-policy-gateway";
+
+const gateway = new PolicyGateway({
+  resolveToken,
+  codeAsPolicyGuard: new DefaultCodeAsPolicyGuard({
+    allowedPrimitives: [
+      "bounding_box",
+      "detect_in_base",
+      "preset",
+      "approach_until",
+      "reset_home",
+    ],
+    maxTrialBudget: 1_000,
+  }),
+});
+```
+
+Requests for generated robot programs carry `params.codeAsPolicy` metadata:
+
+```json
+{
+  "codeAsPolicy": {
+    "programRef": "sint://program/code-policy/fold-shirt.py",
+    "programDigest": "digest:sha256:...",
+    "approvedProgramDigest": "digest:sha256:...",
+    "skillRef": "sint://skill/fold-grasp/v4",
+    "skillDigest": "digest:sha256:...",
+    "approvedSkillDigest": "digest:sha256:...",
+    "primitiveSetRef": "sint://primitive-set/manipulation-safe-v1",
+    "primitives": ["bounding_box", "detect_in_base", "approach_until"],
+    "robotIds": ["arm-left-01", "arm-right-01"],
+    "trialIndex": 12,
+    "trialBudget": 100
+  }
+}
+```
+
+The guard denies before tier assignment when metadata is missing, a digest no
+longer matches the approved artifact, a new primitive appears, duplicate robot
+IDs are present, or the trial loop exceeds its budget. Violations emit
+`robot.code_policy.guard_violation`.

docs/guides/spatial-integrity-policy.md

@@ -0,0 +1,68 @@
+# Spatial Integrity Policy
+
+SINT's spatial integrity policy turns degraded localization from a demo-time
+assumption into a deployment-time gate. It is intended for physical AI rollouts
+where GPS, connectivity, perception, or map freshness cannot be treated as
+ambient guarantees.
+
+The policy is opt-in through `PolicyGatewayConfig.spatialIntegrityPolicy`. It
+runs after token validation and before normal tier assignment, so it can stop or
+escalate physical actions before a bridge reaches ROS 2, MAVLink, Open-RMF, OPC
+UA, or humanoid/robot control surfaces.
+
+## Default Profiles
+
+`DefaultSpatialIntegrityPolicy` includes three deployment profiles:
+
+| Profile | Use case | Default behavior |
+|---|---|---|
+| `gps-denied-indoor` | Warehouses, facilities, public-safety interiors | Requires pose, frame, fresh localization, confidence >= 0.7; escalates below 0.9 |
+| `underground-inspection` | Tunnels, mines, basements, utility corridors | Requires pose, frame, fresh localization, confidence >= 0.75; escalates below 0.92 |
+| `contested-airspace` | Degraded GNSS or adversarial RF environments | Requires pose, frame, fresh localization, confidence >= 0.8; escalates below 0.95 |
+
+Observe-only actions such as sensor subscriptions are not blocked by these
+profiles. The policy applies to physical actions such as velocity commands,
+joint commands, gripper/end-effector calls, MAVLink/PX4 commands, Open-RMF
+actions, and industrial control resources.
+
+## Example
+
+```ts
+import {
+  DefaultSpatialIntegrityPolicy,
+  PolicyGateway,
+} from "@pshkv/gate-policy-gateway";
+
+const gateway = new PolicyGateway({
+  resolveToken,
+  spatialIntegrityPolicy: new DefaultSpatialIntegrityPolicy(),
+});
+```
+
+A GPS-denied physical request should carry localization evidence:
+
+```ts
+{
+  executionContext: {
+    deploymentProfile: "gps-denied-indoor"
+  },
+  physicalContext: {
+    currentPosition: { x: 12.4, y: 3.1, z: 0 },
+    frameId: "map:warehouse-a:v17",
+    localizationConfidence: 0.94,
+    localizationObservedAt: "2026-07-31T09:30:00.000000Z"
+  }
+}
+```
+
+## Decision Model
+
+- Missing required position or frame evidence: deny.
+- Missing or stale `localizationObservedAt`: deny.
+- Confidence below `minLocalizationConfidence`: deny.
+- Confidence below `minAutonomousLocalizationConfidence`: escalate to T2 human review.
+- Fresh high-confidence evidence: continue through normal SINT tiering and token constraints.
+
+Token `executionEnvelope` spatial proof remains the stricter per-token control.
+Use this deployment policy when an entire site profile should fail closed even
+if a token was issued without explicit spatial proof requirements.

docs/index.md

@@ -53,6 +53,7 @@ limits, and tamper-evident audit evidence before execution.
 - NIST submission playbook: [Guide](./guides/nist-submission-playbook.md)
 - Mission Authority reference gateway: [Guide](./guides/mission-authority-reference-gateway.md)
 - Regulated agent runtime quickstart: [Guide](./guides/regulated-agent-runtime-quickstart.md)
+- Spatial integrity policy: [Guide](./guides/spatial-integrity-policy.md)
 - Community launch runbook: [Discord Launch](./community/discord-launch-runbook.md)
 - AAIF RFC-001 submission packet: [Community/AAIF Packet](./community/aaif-rfc001-submission-packet.md)
 - Discord launch kit: [Community/Discord Launch Kit](./community/discord-launch-kit.md)
@@ -61,6 +62,7 @@ limits, and tamper-evident audit evidence before execution.
 - Physical AI runtime safety working group: [Community/Working Group](./community/physical-ai-runtime-safety-working-group.md)
 - Industrial humanoid shipyard safety pack: [Guide](./guides/industrial-humanoid-shipyard-safety-pack.md)
 - Industrial humanoid shipyard safety sprint: [Roadmap](./roadmaps/industrial-humanoid-shipyard-safety-sprint.md)
+- Code-as-policy robot agent safety: [Guide](./guides/code-as-policy-robot-agent-safety.md)
 - Shipyard humanoid evidence export sample: `docs/reports/shipyard-humanoid-evidence-export.jsonl`
 - OWASP Agentic Landscape submission packet: [Community/OWASP Packet](./community/owasp-agentic-landscape-submission.md)
 - EU AI Act mapping: [Compliance/EU AI Act](./compliance/eu-ai-act-mapping.md)

docs/social/launch-checklist.md

@@ -6,10 +6,12 @@ Day-of sequence. Work top to bottom — each step depends on the previous.
 
 ## Pre-Launch (Do First)
 
-- [ ] `git pull --rebase` — confirm on latest master
+- [ ] `git pull --rebase` — confirm on latest `main`
 - [ ] `pnpm run build && pnpm run test` — all 1,105 tests pass
 - [ ] `pnpm run demo:interceptor-quickstart` — demo transcript prints allow, escalate, and fail-closed paths
 - [ ] `pnpm run docs:build` — quickstart guide resolves cleanly in docs site
+- [ ] `npm view sint-mcp version` — public npm version matches `.mcp/server.json`
+- [ ] `npx -y sint-mcp --help` — published package prints CLI help from a clean directory
 
 ---