docs: reclassify Tier 5 -> Tier 2 (Platform) with Tier-5 dashboard surface (#110)

* docs(charter,chitty,claude): reclassify Tier 5 → Tier 2 platform with Tier-5 surface; add meta endpoints and dependencies

Stacked follow-on to PR #106 (ADR-001 + executor registry). Documentation-only
PR that brings the compliance triad and `/api/v1/status` in line with the
ADR-001 amendment that landed on `feat/meta-executors-registry`.

CHARTER.md / CHITTY.md / CLAUDE.md
- Canonical phrasing: "Tier 2 (Platform) with Tier-5 dashboard surface"
  everywhere a tier is declared.
- RY (Authority) row rewritten to reflect sovereignty enforcement + intent
  execution + multi-source ingest. No longer a pure consumer.
- API contract gains the one real new endpoint introduced by #106:
  POST /api/v1/intents/:id/execute. Per the global no-fake-endpoints rule,
  the planned intent CRUD (POST /api/v1/intents, GET .../:id, GET ...,
  GET /api/v1/executors) is NOT documented here because it isn't implemented;
  it will be added when the routes are.
- New Executor Registry table with canonical URI
  chittycanon://core/services/chittycommand/executors/{intent_type}. Lists
  the one executor that actually self-registers today
  (update_obligation_status). mercury_payment is flagged as a tracked future
  executor with REAL-MONEY constraints (fresh autonomous sovereignty,
  USD 500 per-intent cap) and explicitly NOT documented as registered.
- New Cluster Runtime section: daemon is launchd/systemd, NOT a Worker;
  per-node L-type ChittyIDs register as sub-channels via
  agent.chitty.cc/api/v1/channels, NOT in the main ChittyRegister payload.
- Dependencies expanded: ChittyTrust, ChittyID, chittyagent-orchestrator,
  chittyagent-tasks, chittyagent-ch1tty added. ChittyConnect entry expanded
  to call out ContextConsciousness + MemoryCloude (forever context) and
  sensitive-intent secret brokerage.
- Compliance section flags the ChittyID re-mint as required operator
  action (T → P-Synthetic) and explicitly defers /health real-probes and
  tail_consumers wiring to separate PRs.
- MCP tool count reconciled to 50 (CLAUDE.md was already correct; CHARTER/
  CHITTY updated from stale "48").

src/index.ts
- /api/v1/status returns tier: 2 plus tierSurface phrasing and a
  meta.endpoints array listing the registered intent-execute route.
  No other route, middleware, or handler touched.

src/routes/meta.ts
- /api/v1/canon returns tier: 2 + tierSurface so the public canon view
  matches /status and the docs. Same handler signature; no behavior change.

Not in this PR (deferred):
- Real-dependency /health probes (separate PR).
- tail_consumers wiring to chittytrack (separate observability PR).
- ChittyRegister payload submission (operator action; blocked on re-mint).
- Re-mint of service ChittyID as P-Synthetic (operator action).
- Intent CRUD endpoints and /api/v1/executors enumeration (future PRs).

Compliance coverage:
- Addresses: tier reclassification, RY language, meta endpoint surface,
  executor URI registry, dependency expansion, cluster sub-channel
  declaration (items 1, 4, 5, 7, 8 of the registration-readiness audit).
- Remaining (out of scope): registration submission (item 2, operational),
  real /health (item 3, separate PR), tail_consumers (item 6, separate PR),
  P-type ChittyID re-mint (item 9, operator action).

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

* docs(charter): clarify Worker vs daemon runtime split in Classification

Addresses Codex P2 on PR #110: the previous wording said the Tier-2
platform and Tier-5 surface 'both run from the same worker', which
contradicts the Cluster Runtime section stating daemon/ runs as a
supervised launchd/systemd process, not as a Worker.

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

* docs(registration): draft chittycommand Tier-2 registration payload + submission runbook (#111)

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: chitcommit <noreply@chitty.cc>

Author: 3 people

CHARTER.md

@@ -32,10 +32,18 @@ This section is a persistent discovery hint for humans and agents. It is not an
 
 ## Classification
 - **Canonical URI**: `chittycanon://core/services/chittycommand`
-- **Tier**: 5 (Application)
+- **Tier**: 2 (Platform) with Tier-5 dashboard surface
 - **Organization**: CHITTYOS
 - **Domain**: command.chitty.cc
 
+Per [ADR-001](docs/architecture/ADR-001-meta-orchestrator-extension.md), ChittyCommand is reclassified from Tier 5 Application to **Tier 2 (Platform) with Tier-5 dashboard surface**. The platform tier covers the meta-orchestrator (`meta/`), executor registry, sovereignty gate, and cluster daemon (`daemon/`). The Tier-5 surface is the existing user-facing dashboard + ActionAgent + MCP at `command.chitty.cc`.
+
+Deployment artifacts split across two runtimes (see Cluster Runtime section below):
+- **Cloudflare Worker** (`src/`, `meta/` HTTP routes, dashboard, ActionAgent, MCP): the Tier-5 surface and the meta-orchestrator's request-handling plane run from the same Worker at `command.chitty.cc`.
+- **Persistent daemon** (`daemon/`): the cluster leader / intent dispatcher does **not** run as a Worker. It is supervised as a launchd (macOS) / systemd (Linux) process on ChittyServ nodes and connects to the same Neon DB as the Worker.
+
+The dashboard is one consumer of the platform among many.
+
 ## Mission
 
 Provide a unified life management and action dashboard that ingests data from 15+ financial, legal, and administrative sources, scores urgency with AI, recommends actions, and executes them via APIs, email, or browser automation.
@@ -80,12 +88,17 @@ Provide a unified life management and action dashboard that ingests data from 15
 | Upstream | ChittyScrape | Browser-based scraping for portals without APIs |
 | Upstream | ChittyLedger | Evidence and document ledger sync |
 | Upstream | ChittyEvidence | Evidence facts, documents, entities for case timelines |
-| Upstream | ChittyConnect | Inter-service connectivity and discovery |
+| Upstream | ChittyConnect | Inter-service connectivity and discovery; **forever-context** read/write via ContextConsciousness + MemoryCloude; **sensitive-intent secret brokerage** path for all credential access (no inline secrets) |
 | Upstream | ChittyRouter | Unified ingestion gateway (scrape, email routing) |
 | Upstream | ChittySchema | Canonical schema validation and drift detection |
 | Upstream | ChittyCert | Certificate verification |
 | Upstream | ChittyRegister | Service registration, beacon, compliance |
 | Upstream | ChittyChat | Project/task data API |
+| Upstream | ChittyTrust | Sovereignty gate — trust score / autonomy assessment for actor + intent (`meta/sovereignty.ts`) |
+| Upstream | ChittyID | Identity minting — service ChittyID (re-mint pending: P-Synthetic) and per-node L-type IDs for cluster nodes |
+| Upstream | chittyagent-orchestrator | Intent routing + cross-channel fanout via `POST agent.chitty.cc/agent/message` |
+| Upstream | chittyagent-tasks | Durable distributed task queue pattern reused for intent dispatch + `node_leases` (mirrors `task_leases`) |
+| Upstream | chittyagent-ch1tty | MCP portal / OAuth gateway — `command` listed as upstream in `AGENT_MCP_UPSTREAMS` |
 | Platform | Cloudflare Workers | Compute runtime |
 | Platform | Cloudflare R2 | Document storage |
 | Platform | Cloudflare KV | Sync state, auth tokens, service tokens |
@@ -130,7 +143,32 @@ Provide a unified life management and action dashboard that ingests data from 15
 | `/api/v1/jobs/:id/retry` | POST | Bearer | Retry failed scrape job |
 | `/api/v1/jobs/dead-letters` | GET | Bearer | Dead letter queue |
 | `/api/bridge/*` | Various | Service/Bearer | Inter-service bridge routes |
-| `/mcp/*` | Various | Service | MCP server (48 tools across 12 domains) |
+| `/api/v1/intents/:id/execute` | POST | Bearer | Dispatch a queued Intent through the executor registry (sovereignty re-checked at executor entry) |
+| `/mcp/*` | Various | Service | MCP server (50 tools across 12 domains) |
+
+### Executor Registry
+
+Canonical URI namespace: `chittycanon://core/services/chittycommand/executors/{intent_type}`
+
+Executors self-register at module load (side-effect imports from `meta/executors/index.ts`). The dispatcher (`meta/executors/dispatch.ts`) looks executors up by `intent_type`; absence is a wiring bug, not a runtime error. Per ADR-001, the sovereignty gate (`meta/sovereignty.ts`) is invoked at executor entry and re-reckoned if the persisted snapshot is older than the configured freshness window.
+
+| `intent_type` | Canonical URI | Notes |
+|---------------|---------------|-------|
+| `update_obligation_status` | `chittycanon://core/services/chittycommand/executors/update_obligation_status` | Real Neon write to `cc_obligations`. Source: `meta/executors/update-obligation-status.ts` |
+
+> **Future executors** (e.g. `mercury_payment` — 🔒 REAL-MONEY, will require fresh `autonomous` sovereignty assessment and an enforced USD 500 per-intent cap) are tracked in ADR-001 but are NOT yet registered in `meta/executors/index.ts`. They will be added in follow-up PRs and listed here at the same time the executor file is committed. This table is the authoritative list of currently-registered executors — do not document executors that do not exist.
+
+### Cluster Runtime
+
+Per [ADR-001](docs/architecture/ADR-001-meta-orchestrator-extension.md), the persistent cluster daemon (`daemon/`) is **not** a Cloudflare Worker. It runs as a supervised long-lived process on each ChittyServ cluster node:
+
+- **Hosts**: `chittymini-01..06` (Mac Mini 2012 homelab) + `chittyserv-vm`
+- **Supervision**: launchd on macOS Minis, systemd on Ubuntu Minis + VM
+- **Leader election**: Float-free across cluster via Neon `node_leases` (atomic `UPDATE ... RETURNING`, mirrors `task_leases` shape)
+- **Loop**: claim → execute (via the same `meta/executors/*` registry the Worker uses) → heartbeat → release
+- **Neon-loss fallback**: Park the node (MVP) — avoids split-brain; LAN gossip is a follow-up
+
+**Channel registration** for cluster nodes is explicitly **out of scope for the main ChittyRegister service payload**. Each node mints its own L-type ChittyID and registers as a **sub-channel** via `POST agent.chitty.cc/api/v1/channels` (per the ADR-001 preferred path). A future ChittyRegister submission for `chittycommand` must NOT attempt to model the cluster daemon as Worker compute, additional routes, or service bindings — the daemon is a peer execution surface to the Worker, not part of its deploy artifact.
 
 ### Cron Schedule
 | Schedule | Purpose |
@@ -156,7 +194,7 @@ Source: `chittycanon://gov/governance#three-aspects`
 |--------|--------|----------|--------------------|
 | **Identity** | TY | What IS it? | Unified life management dashboard — ingests financial, legal, and administrative data from 15+ sources, scores urgency, recommends and executes actions |
 | **Connectivity** | VY | How does it ACT? | Cron-scheduled syncs (Plaid, Mercury, court dockets, utilities); bridge API to ChittyScrape, ChittyLedger, ChittyFinance; MCP server for Claude-driven queries; action execution via API, email, or browser automation |
-| **Authority** | RY | Where does it SIT? | Tier 5 Application — consumer of upstream data, not source of truth; delegates scraping to ChittyScrape, identity to ChittyID, financials to ChittyFinance |
+| **Authority** | RY | Where does it SIT? | Tier 2 (Platform) with Tier-5 dashboard surface — sovereign meta-orchestrator that enforces trust gates on intent execution, dispatches actions across registered executors and channels, and ingests from 15+ upstreams. Source of truth for: intent ladder (`cc_intents`), executor registry, sovereignty assessments, cluster node leases. Still delegates: identity to ChittyID, browser scraping to ChittyScrape, financial aggregation to ChittyFinance, forever-context storage to ChittyConnect (ContextConsciousness + MemoryCloude). |
 
 ## Document Triad
 
@@ -175,12 +213,15 @@ This charter is part of a synchronized documentation triad. Changes to shared fi
 
 ## Compliance
 
-- [x] Service registered in ChittyRegister (03-1-USA-3846-T-2602-0-57, pending_cert)
+- [x] Service registered in ChittyRegister (03-1-USA-3846-T-2602-0-57, pending_cert) — ⚠️ **DEPRECATED PENDING RE-MINT** (see below)
 - [x] Health endpoint operational at /health
-- [x] Status endpoint operational at /api/v1/status
+- [x] Status endpoint operational at /api/v1/status (reflects Tier 2 + meta endpoints)
 - [x] CLAUDE.md development guide present
 - [x] CHARTER.md present
 - [x] CHITTY.md present
+- [ ] **ChittyID re-mint required (operator action, blocks Tier 2 ChittyCertify).** The currently registered ChittyID `03-1-USA-3846-T-2602-0-57` encodes type `T` (Thing). Per `chittycanon://gov/governance#core-types` and the global "actors with agency are always Person" rule, a sovereign meta-orchestrator that takes autonomous action (intent execution, sovereignty enforcement, channel fanout) is a **Person — Synthetic** (P-Synthetic), not a Thing. A new ChittyID must be minted as `VV-G-USA-NNNN-P-YM-S-X` (T-slot = `P`, subtype Synthetic) and the registry record updated. The existing T-type ID is retained for historical lookup only and must NOT be cited as the service identity in new code, telemetry, or downstream contracts after the re-mint. **Blocks**: formal ChittyCertify at Tier 2; sovereign-intent signing; ChittyTrust score binding for the service-as-actor.
+- [ ] Real-dependency `/health` probes (db / chittyconnect / daemon-heartbeat) — tracked in a separate PR; not in this docs PR.
+- [ ] Service-level `tail_consumers` wiring (`chittytrack`) — tracked in a separate observability PR; not in this docs PR.
 
 ---
-*Charter Version: 1.2.0 | Last Updated: 2026-03-24*
+*Charter Version: 1.3.0 | Last Updated: 2026-06-04*

CHITTY.md

@@ -17,7 +17,7 @@ discovery_refs:
 
 # ChittyCommand
 
-> `chittycanon://core/services/chittycommand` | Tier 5 (Application) | command.chitty.cc
+> `chittycanon://core/services/chittycommand` | Tier 2 (Platform) with Tier-5 dashboard surface | command.chitty.cc
 
 <!-- chitty:discovery-links:start -->
 ## Persistent Context
@@ -71,7 +71,7 @@ Source: `chittycanon://gov/governance#three-aspects`
 |--------|--------|--------|
 | **Identity** | TY | Unified life management dashboard — ingests financial, legal, and administrative data from 15+ sources, scores urgency, recommends and executes actions |
 | **Connectivity** | VY | Cron-scheduled syncs (Plaid, Mercury, court dockets, utilities); bridge API to ChittyScrape, ChittyLedger, ChittyFinance; MCP server for Claude-driven queries; action execution via API, email, or browser automation |
-| **Authority** | RY | Tier 5 Application — consumer of upstream data, not source of truth; delegates scraping to ChittyScrape, identity to ChittyID, financials to ChittyFinance |
+| **Authority** | RY | Tier 2 (Platform) with Tier-5 dashboard surface — sovereign meta-orchestrator that enforces trust gates on intent execution, dispatches actions across registered executors and channels, and ingests from 15+ upstreams. Source of truth for: intent ladder (`cc_intents`), executor registry, sovereignty assessments, cluster node leases. Still delegates: identity to ChittyID, browser scraping to ChittyScrape, financial aggregation to ChittyFinance, forever-context storage to ChittyConnect (ContextConsciousness + MemoryCloude). _Canonical source: [CHARTER.md](CHARTER.md#three-aspects-ty-vy-ry)._ |
 
 ## ChittyOS Ecosystem
 
@@ -85,6 +85,11 @@ Source: `chittycanon://gov/governance#three-aspects`
 - **DNA Hash**: --
 - **Lineage**: root (life management)
 
+### Ecosystem Position
+
+- **Upstream**: ChittyAuth, ChittyTrust, ChittyID, ChittyConnect (ContextConsciousness + MemoryCloude + sensitive-intent secret brokerage), chittyagent-orchestrator (routing + channel fanout), chittyagent-tasks (queue + lease pattern), chittyagent-ch1tty (MCP portal/OAuth), ChittyFinance, ChittyBooks, ChittyAssets, ChittyCharge, ChittyScrape, ChittyLedger, ChittyEvidence, ChittyRouter, ChittySchema, ChittyCert, ChittyRegister, ChittyChat.
+- **Downstream / sub-channels**: ChittyServ cluster nodes (`chittymini-01..06`, `chittyserv-vm`) — each runs a supervised `daemon/` process and registers as an L-type sub-channel via `agent.chitty.cc/api/v1/channels`. ActionAgent (chat surface) and dashboard SPA at `app.command.chitty.cc` are sibling consumers of the same `meta/executors/*` registry.
+
 ### Dependencies
 
 See [CHARTER.md](CHARTER.md) (Dependencies section) — canonical source for the full dependency graph.
@@ -130,7 +135,8 @@ See [CHARTER.md](CHARTER.md) (Dependencies section) — canonical source for the
 | `/api/v1/jobs/:id` | GET | Bearer | Scrape job details |
 | `/api/v1/jobs/:id/retry` | POST | Bearer | Retry failed scrape job |
 | `/api/v1/jobs/dead-letters` | GET | Bearer | Dead letter queue |
-| `/mcp/*` | Various | Service | MCP server (48 tools across 12 domains) |
+| `/api/v1/intents/:id/execute` | POST | Bearer | Dispatch a queued Intent through the executor registry (sovereignty re-checked at executor entry) |
+| `/mcp/*` | Various | Service | MCP server (50 tools across 12 domains) |
 
 ## Document Triad
 

CLAUDE.md

@@ -19,7 +19,7 @@ ChittyCommand is a unified life management and action dashboard for the ChittyOS
 **Repo:** `CHITTYOS/chittycommand`
 **Deploy:** Cloudflare Workers at `command.chitty.cc` (alias: `disputes.chitty.cc`)
 **Stack:** Hono TypeScript, React + Tailwind, Neon PostgreSQL (via Hyperdrive), Cloudflare R2/KV
-**Canonical URI:** `chittycanon://core/services/chittycommand` | Tier 5
+**Canonical URI:** `chittycanon://core/services/chittycommand` | Tier 2 (Platform) with Tier-5 dashboard surface
 
 ## Common Commands
 
@@ -41,7 +41,16 @@ wrangler secret put DATABASE_URL
 
 ## Architecture
 
-Single Cloudflare Worker (`chittycommand`) serving API + cron. Frontend is a separate React SPA at `app.command.chitty.cc` (Cloudflare Pages).
+Per [ADR-001](docs/architecture/ADR-001-meta-orchestrator-extension.md), ChittyCommand is a Tier-2 platform with a Tier-5 dashboard surface. The Cloudflare Worker (`chittycommand`) and a separate supervised cluster daemon both consume the same canonical executor registry.
+
+### Tier-2 Platform Layers
+
+- **`meta/`** — Goal → Plan → Intent ladder (`meta/intent.ts`), sovereignty gate (`meta/sovereignty.ts`, trust-score → `autonomous | requires_human | blocked`), channel fanout (`meta/channels.ts`), forever-context wrapper (`meta/context.ts`), and the **executor registry** (`meta/executors/*`) with self-registration at module load. Canonical executor URIs: `chittycanon://core/services/chittycommand/executors/{intent_type}`. The sovereignty gate is invoked at (1) Intent creation (persisted into `cc_intents.sovereignty_assessment`) and (2) executor entry in `meta/executors/dispatch.ts` (re-reckoned if snapshot is older than the configured freshness window). Execution audit is additive columns on `cc_actions_log` — NOT a new table.
+- **`daemon/`** — Persistent supervised cluster process (launchd / systemd) running on each ChittyServ node. Leader election via Neon `cc_node_leases` (mirrors `task_leases` shape, atomic `UPDATE ... RETURNING`). Loop: claim → execute (same executor registry) → heartbeat → release. Float-free leadership; Neon-loss fallback is "park the node" (MVP).
+
+### Tier-5 Dashboard Surface
+
+Single Cloudflare Worker (`chittycommand`) serving API + cron + ActionAgent + MCP. Frontend is a separate React SPA at `app.command.chitty.cc` (Cloudflare Pages). ActionAgent (chat surface) and the cluster daemon (autonomous surface) are **siblings** that consume the same `meta/executors/*` registry; neither dispatches the other.
 
 ### Data Sources
 

docs/registration/SUBMISSION_RUNBOOK.md

@@ -0,0 +1,88 @@
+# ChittyCommand Registration Submission Runbook
+
+Operator-facing runbook for submitting `chittycommand` to `register.chitty.cc` as a Tier-2 platform service. The payload draft lives alongside this file at `chittycommand-registration-payload.json`.
+
+This runbook does NOT submit. Submission is a separate, gated operator action routed through ChittyConnect (the Chico concierge).
+
+## Pre-requisites
+
+1. **Stacked PRs merged to `main`, in order:**
+   - PR #106
+   - PR #107
+   - PR #109
+   - PR #110 (Tier-2 reclassification — CHARTER/CHITTY/CLAUDE updates)
+
+   This PR (registration payload draft) is stacked on #110 and should merge AFTER #110 lands on main.
+
+2. **Live pre-flight health probe:**
+
+   ```bash
+   curl -sS https://command.chitty.cc/health | jq .
+   ```
+
+   Must return the real-dependency probe JSON shape — fields for `db`, `chittyconnect`, and `daemon` heartbeat must reflect actual probed state. A static `{"status":"ok"}` response is a regression and blocks submission per the global "no fake/non-working endpoints" rule.
+
+3. **New P-Synthetic ChittyID minted** via the canonical Chico path:
+
+   - Route: `ch1tty → ChittyConnect → chittyid`
+   - The previous ID `03-1-USA-3846-T-2602-0-57` is deprecated because the 5th field encoded `T` (Thing). `chittycommand` is a sovereign actor and must be `P` (Person, Synthetic characterization).
+   - Verify the minted ID's 5th `-`-separated field is `P` before substituting into the payload.
+
+## Substitutions Before Submission
+
+The committed payload contains two placeholder strings. Both must be substituted at submission time. NEITHER value is ever pasted into chat, committed to git, or stored in shell history in plaintext.
+
+| Placeholder | Substitution Source | Routing |
+|---|---|---|
+| `<<CHITTY_REGISTER_TOKEN>>` | 1Password (cold source) → Cloudflare Secrets (runtime) | ChittyConnect via Chico — operator never handles the bearer directly |
+| `<<PENDING_P_SYNTHETIC_CHITTYID>>` | Newly minted via ChittyID service | Operator confirms `P` in 5th field, then injects |
+
+Per `/home/ubuntu/.ch1tty/canon/system-wide-sensitive-intent-contract-v1.md`, the operator does not paste secrets — the request must route through ChittyConnect. If the broker path is unavailable, fail closed with `POLICY_BLOCKED_CHITTYCONNECT_UNAVAILABLE`.
+
+## Submission Command (shape only)
+
+The actual injection uses `op run` per the operator manifest. The template below shows the request shape — do NOT run it verbatim with raw env vars.
+
+```bash
+jq '.registrationToken="$CHITTY_REGISTER_TOKEN" | .service.chittyId="$NEW_CHITTYID"' \
+   docs/registration/chittycommand-registration-payload.json | \
+   curl -sS -X POST https://register.chitty.cc/api/v1/register \
+     -H "Authorization: Bearer $CHITTY_REGISTER_TOKEN" \
+     -H "content-type: application/json" \
+     --data @-
+```
+
+Production invocation wraps the above under `op run --env-file=... --` with the token resolved by ChittyConnect at request time.
+
+## Verification
+
+After a 2xx response from `register.chitty.cc`:
+
+```bash
+curl -sS 'https://registry.chitty.cc/api/v1/search?q=chittycommand' | jq .
+```
+
+Expected: the new entry is returned with `tier: 2`, `category: "core-infrastructure"`, and the new P-Synthetic ChittyID.
+
+Record the verification response (with the token field redacted) in a follow-up commit to `CHARTER.md` under a "Registration Evidence" section.
+
+## ChittyCertify Next Step
+
+Once registered, `chittycommand` is eligible for Tier-2 ChittyCertify audit. Open the audit request via the canonical ChittyCertify intake — do not self-assert the certification level in the payload (the payload's `certificationLevel` is `null` by design; ChittyCertify writes it).
+
+## Rollback / Failure Handling
+
+If `register.chitty.cc` rejects the submission:
+
+1. Capture the full response body (headers + JSON) — redact token-shaped fields before storing.
+2. Do NOT retry blindly.
+3. File an issue against `chittyos/chittyregistry` referencing this runbook, the response body, and the payload shape (NOT the resolved token).
+4. Diagnose the schema or auth mismatch before any second attempt. The `ServiceRegistrationSchema` in `chittyregistry/src/types/index.ts` is the authoritative shape — payload must match.
+
+## What This Runbook Does NOT Do
+
+- Does not submit the registration.
+- Does not handle the bearer token directly — Chico/ChittyConnect owns that.
+- Does not modify CHARTER/CHITTY/CLAUDE (PR #110's lane).
+- Does not deploy any worker.
+- Does not enable auto-merge on this PR.