Add Motion: the go-to-market operating system on top of the ledger

The ledger answers which contracted capacity is sold, to whom, at what
margin. It says nothing about the motion — the repeatable practice that
turns a customer conversation into a scoped deployment, and turns that
deployment into something the next one reuses.

Motion is deliberately not a parallel entity tree. DEMAND_STAGES already
is the motion, so Motion binds reusable artefacts to the stages of a
demand deal that already exists: an engagement hangs off one deal,
cascade deleted, one per deal by unique constraint.

Nine closed kinds, each declaring which stages it serves, and a starter
library of twelve templates covering all eight open stages.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -173,6 +173,7 @@ thesis:
 | `contracts` + `sla_terms` + `sla_metric_targets` + `contract_obligations` | Polymorphic over party and type — MSA, DPA, SLA, order form, capacity commitment — with negotiated SLA terms and dated obligations | The supply side negotiates heavyweight paper; the self-serve demand side runs on a reliability tier and a credits policy instead |
 | `export_authorizations`, `compliance_artifacts`, `compliance_decisions` | Export-control determinations recorded **on the allocation edge**, with reasoning and rule version | US controls apply an ultimate-parent test that reaches through the corporate tree, so country of incorporation is not a valid key |
 | `facts` | Every agent-derived claim, with score, band, evidence excerpt and source URL | An agent allowed to write unattributed claims will eventually write a wrong one and nobody will be able to tell which |
+| `motion_templates` + `engagements` + `engagement_artifacts` + `qualification_scores` | The go-to-market motion: a reusable library bound to the stages of a demand deal, and the artefacts each engagement produced | A used template is never edited in place — promotion writes a **new version** pointing back at the artefact that proved it, which is what makes the next deployment cheaper than the last |
 | `agent_tasks` / `agent_runs` / `agent_actions` | The queue the API writes to and the agent drains, plus what it did | The API never calls the model; it writes a row |
 
 Two pipelines, with stages taken from how the market operates:
@@ -351,13 +352,13 @@ apps/
   web/        React 19 + Vite + Tailwind + shadcn-idiom components
   api/        Hono HTTP API — auth, validation, capacity and contract services
   piggy/      The agent: a lease-based queue worker plus a private chat server
-  mcp/        MCP server (stdio) — 9 tools
+  mcp/        MCP server (stdio) — 10 tools
   cli/        `pig`, the HTTP surface for scripts and agent kernels
 packages/
   core/       Ontology, permissions, margin arithmetic, palette — no I/O
-  db/         Drizzle schema (47 tables), 14 migrations, seed and demo data
+  db/         Drizzle schema (51 tables), 15 migrations, seed and demo data
   prime/      Typed client for the Prime Intellect compute API
-docs/         ontology.md, screenshots.md, build-plan.md, agents.md, seed-data.md
+docs/         ontology.md, motion.md, screenshots.md, build-plan.md, agents.md, seed-data.md
 deploy/       Caddyfile example, autodeploy units, deployment notes
 ```
 
@@ -590,6 +591,7 @@ responsive to 393px; it is not a native app.
 - [Screenshots](./docs/screenshots.md) — every page, at 1440px and 393px, light and dark
 - [Ontology](./docs/ontology.md) — the domain model, and why it is shaped this way
 - [Build plan](./docs/build-plan.md) — what shipped, what remains, in dependency order
+- [Motion](./docs/motion.md) — the template library, the promotion loop, and the private/shared departure
 - [Agent integration](./docs/agents.md) — MCP clients and the CLI
 - [Seed data provenance](./docs/seed-data.md) — every claim, graded and cited
 - [Deployment](./deploy/README.md) — self-hosting, the release poller, rollback