Merge origin/main into feat/adr-0091-l2-delegation — resolve proof-registry conflicts

Both this branch and the merged ADR-0057 lifecycle work (#2791) appended a
HIGH_RISK_CLASSES entry and extended the BOUND_PROOF_PATHS expectation:
kept BOTH ('delegation' → position/delegatable, 'data-lifecycle' →
object/lifecycle). proof-registry tests and the spec-liveness gate pass on
the merged tree.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BNBzMWmSECrbiEDdVzwBt3

Author: claude

.changeset/adr-0057-lifecycle-p1-p4.md

@@ -0,0 +1,20 @@
+---
+'@objectstack/spec': minor
+'@objectstack/objectql': minor
+'@objectstack/driver-sql': minor
+'@objectstack/driver-sqlite-wasm': minor
+'@objectstack/platform-objects': minor
+'@objectstack/metadata-core': minor
+'@objectstack/service-messaging': minor
+'@objectstack/service-automation': minor
+'@objectstack/plugin-audit': minor
+---
+
+ADR-0057 data lifecycle P1–P4 (#2786): platform-generated data is now bounded by construction.
+
+- **P1 — contract**: new `lifecycle` object property (`class: record | audit | telemetry | transient | event` + `retention` / `ttl` / `storage(rotation)` / `archive` / `reclaim`), enforced by the platform-owned **LifecycleService** registered by `ObjectQLPlugin` (default-on; disable via `OS_LIFECYCLE_DISABLED=1` or plugin `lifecycle.enabled=false`). The Reaper batch-deletes rows past `retention.maxAge` / `ttl` under a system context and reclaims space (`SqlDriver.reclaimSpace()` → SQLite `PRAGMA incremental_vacuum`). Non-`record` classes must declare a bounding policy (parse-time invariant + spec-liveness gate + dogfood storage-growth gate).
+- **P2 — rotation**: `storage: { strategy: 'rotation', shards, unit }` physically time-shards the table on SQLite — writes land in the current shard, reads go through a UNION-ALL view under the base name, expiry is an O(1) `DROP` of shards past the window. A legacy table is adopted as the first shard on upgrade. Other dialects fall back to an equivalent age-based reap.
+- **P3 — separation + Archiver**: registering a datasource named `telemetry` routes telemetry/event/audit objects to it (opt-in by existence; `transient` deliberately stays on the primary). Audit objects with `archive` declared get retain → archive → delete once the archive datasource exists; without it rows are retained, never dropped unarchived.
+- **P4 — governance**: new `lifecycle` settings namespace — runtime enable switch, per-object retention overrides (tenant-scoped: regulated tenants set years, dev sets days), per-object/per-class row quotas and growth alerts (observe-and-alert only).
+
+**Behavior change**: 11 platform objects now carry lifecycle declarations and their telemetry is bounded by default — `sys_activity` 14d (rotated), `sys_audit_log` 90d hot → archive (retained forever until an `archive` datasource is registered), `sys_metadata_audit` 365d → archive, `sys_job_run` / `sys_automation_run` / `sys_http_delivery` 30d, notification pipeline (`sys_notification`, delivery, receipt, inbox) 90d, `sys_device_code` expires_at + 1d. Extend windows per environment/tenant via the `lifecycle.retention_overrides` setting.

.changeset/agent-docs-open-edition-honesty.md

@@ -0,0 +1,19 @@
+---
+"@objectstack/spec": patch
+---
+
+Agent capability — open-edition honesty pass (docs + liveness annotation), no
+behavior change:
+
+- The `agent`/`skill`/`tool`/`action` liveness files cite
+  `packages/services/service-ai/...` as evidence, but that tree is a stale,
+  untracked build artifact — the real runtime is the closed cloud
+  `@objectstack/service-ai`. Each file's `_note` now says so explicitly, so an
+  auditor reading the ledger understands these props are `live` because a
+  CLOUD/EE runtime consumes them and the OPEN framework edition does not.
+- Docs (`content/docs/ai`): removed the `aggregate_data` over-claim from
+  Natural Language Queries — the open MCP surface registers 9 tools and
+  `query_records` has no aggregation args; `aggregate_data` is a cloud data
+  tool. And disambiguated the two things called "skill" (authoring `SKILL.md`
+  modules vs. runtime `defineSkill` agent capability bundles) with cross-linked
+  callouts on both pages.

.changeset/docs-sms-phone-otp.md

@@ -0,0 +1,6 @@
+---
+---
+
+Docs-only: `services.sms` runtime-service reference + phone-number
+authentication (SMS OTP) section in the authentication guide. No package
+changes.

content/docs/ai/agents.mdx

@@ -85,11 +85,19 @@ API-key-only, fail-closed.
 
 ## You extend the platform with **skills**, not agents
 
+<Callout type="warn">
+**"Agent skill" ≠ "authoring skill."** The `*.skill.ts` / `defineSkill` files
+here are **agent skills** — runtime capability bundles the `ask` / `build`
+agents consume. They are a different thing from the `SKILL.md` **authoring
+skills** on the [AI Skills System](/docs/ai/skills) page, which teach a coding
+assistant to *write* your metadata and never run. Same word, two layers.
+</Callout>
+
 `*.agent.ts` is **closed to third parties** — the `agent` metadata type is
 `allowRuntimeCreate:false, allowOrgOverride:false`, reserved for the two platform
 agents and platform-owned subagents (ADR-0063 §2). To give the `ask` agent a new
-capability you author a **skill** (`*.skill.ts`) whose `tools` reference your
-Actions / Flows / queries; it then attaches to `ask`. Every skill declares
+capability you author an agent **skill** (`*.skill.ts`) whose `tools` reference
+your Actions / Flows / queries; it then attaches to `ask`. Every skill declares
 `surface: 'ask' | 'build' | 'both'`, and an agent's tool set is the **union of its
 surface-compatible skills' tools** — there is no global fall-through, so a skill
 reaches an agent only when their surfaces match

content/docs/ai/natural-language-queries.mdx

@@ -1,6 +1,6 @@
 ---
 title: Natural Language Queries
-description: How agents query live data through the built-in data tools (query_records, get_record, aggregate_data) under RLS
+description: How agents query live data through the open MCP data tools (query_records, get_record) under RLS
 ---
 
 # Natural Language Queries
@@ -14,15 +14,25 @@ row-level security as the REST API. The data tools and the ObjectQL engine that
 back this are part of the open framework — no `@objectstack/service-ai` and no
 cloud studio are required.
 
-Your AI queries your data through the built-in **data tools** —
-`query_records`, `get_record`, and `aggregate_data` — which the model calls with
-structured arguments. These run as ordinary [ObjectQL](/docs/protocol/objectql) queries over
+Your AI queries your data through the open MCP **data tools** — `query_records`
+(filter, field selection, sort, pagination) and `get_record`, plus the
+discovery tools `list_objects` and `describe_object` — which the model calls
+with structured arguments. These run as ordinary [ObjectQL](/docs/protocol/objectql) queries over
 your objects (ObjectStack uses ObjectQL, not SOQL), and they execute under the
 caller's `ExecutionContext`, so row-level security applies exactly as it does
 for the REST API.
 
+<Callout type="info">
+**Aggregation is a cloud data tool.** The open MCP surface reads and filters
+rows; it does not ship a server-side `aggregate_data` (group-by / roll-up)
+tool — `query_records` has no aggregation arguments. A BYO agent aggregates by
+fetching the rows it's allowed to see and summing client-side; the built-in
+`aggregate_data` tool is part of the cloud in-product chat runtime (below).
+</Callout>
+
 The open MCP server plugin exposes these tools automatically — it bridges the
-kernel's tool registry, metadata, and data engine to any connected MCP client:
+metadata and data engine to any connected MCP client, served per-request at
+`/api/v1/mcp` (default-on):
 
 ```typescript
 import { LiteKernel } from '@objectstack/core';
@@ -34,28 +44,20 @@ await kernel.bootstrap();
 ```
 
 Point any MCP client at the server and ask questions in natural language: the
-model discovers `query_records` / `get_record` / `aggregate_data` and calls them
-under RLS as the authenticated caller.
+model discovers `list_objects` / `describe_object` / `query_records` /
+`get_record` and calls them under RLS as the authenticated caller.
 
 There is no separate natural-language-to-query metadata type to author — the
 model is prompted with the available objects and translates the user's question
-into `query_records` / `aggregate_data` calls at runtime.
+into `query_records` calls at runtime.
 
 <Callout type="info">
-**Cloud / Enterprise — bundled in-product chat.** The cloud tier's in-UI AI
-runtime (`@objectstack/service-ai`, the `ask` data-query assistant, and the
-`/api/v1/ai/*` chat endpoints) registers these same data tools into its chat
-loop via `registerDataTools`:
-
-```typescript
-import { registerDataTools } from '@objectstack/service-ai';
-
-ctx.hook('ai:ready', async (ai) => {
-  registerDataTools(ai.toolRegistry, { dataEngine: ctx.getService('data') });
-});
-```
-
-This is the cloud runtime, not the open path. On the open edition, use
+**Cloud / Enterprise — bundled in-product chat.** The cloud tier ships an in-UI
+AI runtime (`@objectstack/service-ai`, closed) — the `ask` data-query assistant
+and the `/api/v1/ai/*` chat endpoints — that registers these same data tools,
+plus the group-by/roll-up `aggregate_data` tool, into its own chat loop. That
+package is not part of the open framework and is documented separately in the
+cloud docs; this page covers the open path only. On the open edition, use
 `@objectstack/mcp` above to get the same natural-language querying with your
 own AI.
 </Callout>

content/docs/ai/skills.mdx

@@ -13,6 +13,16 @@ ObjectStack introduces a **Skills System** — structured, domain-specific knowl
 Skills are **not runtime code**. They are machine-readable knowledge definitions that teach AI assistants the ObjectStack protocol — its schemas, patterns, constraints, and best practices.
 </Callout>
 
+<Callout type="warn">
+**Two different things share the word "skill."** This page is about **authoring
+skills** — `SKILL.md` knowledge modules (from `skills.sh`) that teach a coding
+assistant to *write* correct ObjectStack metadata, at development time. They are
+unrelated to **agent skills** (`defineSkill` / `SkillSchema`) — the *runtime*
+capability bundles (tools + instructions + trigger conditions) attached to the
+`ask` / `build` platform agents, which are the cloud in-product chat runtime.
+See [Agents](/docs/ai/agents#you-extend-the-platform-with-skills-not-agents) for those.
+</Callout>
+
 ---
 
 ## Installing skills

content/docs/kernel/runtime-services/index.mdx

@@ -39,6 +39,7 @@ Each page links the canonical TypeScript source used to derive signatures.
 - Sharing: `packages/spec/src/contracts/sharing-service.ts`
 - Queue: `packages/spec/src/contracts/queue-service.ts`
 - Email: `packages/spec/src/contracts/email-service.ts`
+- SMS: `packages/spec/src/contracts/sms-service.ts`
 - Storage: `packages/spec/src/contracts/storage-service.ts`
 - Settings: `packages/services/service-settings/src/settings-service.ts`
 - Audit bridge: `packages/services/service-settings/src/settings-service.types.ts`

content/docs/kernel/runtime-services/meta.json

@@ -7,6 +7,7 @@
     "audit-service",
     "queue-service",
     "email-service",
+    "sms-service",
     "settings-service",
     "storage-service",
     "examples",

content/docs/kernel/runtime-services/sms-service.mdx

@@ -0,0 +1,70 @@
+---
+title: services.sms
+description: Outbound SMS delivery through pluggable providers (Aliyun SMS, Twilio).
+---
+
+# `services.sms`
+
+- **Stability:** `stable`
+- **Canonical source:** `packages/spec/src/contracts/sms-service.ts`
+
+## Methods
+
+```ts
+services.sms.send(input: SendSmsInput): Promise<SendSmsResult>
+services.sms.isConfigured(): boolean
+```
+
+`SendSmsInput` carries the recipient (`to`, E.164 recommended), the rendered
+`body`, and optional provider-template fields (`templateId`,
+`templateParams`) for template-only providers such as Aliyun SMS — which
+refuse free-form bodies and only deliver pre-registered templates.
+
+`isConfigured()` is `false` while the service runs on the development
+`LogSmsTransport` fallback (messages are logged, never delivered). Consumers
+that advertise SMS-dependent features — phone OTP sign-in, SMS invitations —
+gate on it in production (`features.phoneNumberOtp`).
+
+## Returns
+
+`SendSmsResult`:
+
+- `id: string` — correlation id for the attempt
+- `status: 'sent' | 'failed'`
+- `messageId?: string` — provider message id (Aliyun BizId, Twilio SID)
+- `error?: string` — transport detail when `status='failed'`
+
+## No persistence, no body logging
+
+Unlike `services.email` (which persists to `sys_email`), the SMS service
+deliberately has **no persistence surface and never logs message bodies**:
+SMS bodies routinely carry one-time passwords, so a message log would be a
+credential store. Diagnostics log masked recipients and statuses only.
+
+## Configuration
+
+Providers are configured through the `sms` settings namespace
+(Setup → Settings → SMS Delivery), with live rebinding — no restart needed:
+
+- `provider` — `log` (default, no real delivery) / `aliyun` / `twilio`
+- Aliyun: `aliyun_access_key_id`, `aliyun_access_key_secret` (encrypted),
+  `aliyun_sign_name`, `aliyun_template_code` (default catch-all template with
+  a single `${content}` variable for generic notification SMS)
+- Twilio: `twilio_account_sid`, `twilio_auth_token` (encrypted), and
+  `twilio_from_number` or `twilio_messaging_service_sid`
+
+Every key accepts the standard settings env override (`OS_SMS_PROVIDER`,
+`OS_SMS_ALIYUN_ACCESS_KEY_ID`, …). The **Send test SMS** action exercises the
+live (or unsaved) provider configuration.
+
+## Consumers
+
+- **Phone-number OTP auth** — sign-in verification codes and self-service
+  password-reset codes (`/phone-number/*`, see
+  [Authentication](/docs/permissions/authentication)).
+- **Messaging `sms` channel** — `notify(channels:['sms'])` resolves the
+  recipient's `sys_user.phone_number`, renders the `(topic, 'sms', locale)`
+  row from `sys_notification_template`, and delivers through this service
+  with outbox retry/dead-letter.
+- **Identity import SMS invitations** — the `invite` password policy sends a
+  credential-free invitation SMS to phone-only rows.