Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 88 additions & 0 deletions docs/registration/SUBMISSION_RUNBOOK.md
Original file line number Diff line number Diff line change
@@ -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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Align the health preflight with the deployed endpoint

This preflight currently blocks submission because src/index.ts still serves /health as a static { status, service, version, timestamp } response and does not include the db, chittyconnect, or daemon fields required here. Since the runbook says the operator should submit after these stacked PRs merge, either the health implementation needs to be updated in the stack or this requirement will make the documented submission path fail closed every time.

Useful? React with 👍 / 👎.


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"' \

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Expand env values before sending jq output

This jq expression writes the literal strings $CHITTY_REGISTER_TOKEN and $NEW_CHITTYID into the JSON body; I confirmed jq does not expand shell variables inside a quoted filter. Even when op run provides the environment, the Authorization header may use the real token but the submitted registrationToken and service.chittyId fields remain invalid unless the command uses --arg/env.* or an equivalent injection mechanism.

Useful? React with 👍 / 👎.

docs/registration/chittycommand-registration-payload.json | \
curl -sS -X POST https://register.chitty.cc/api/v1/register \
-H "Authorization: Bearer $CHITTY_REGISTER_TOKEN" \

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Avoid putting the bearer token in curl argv

If the operator follows this template under op run, the shell expands $CHITTY_REGISTER_TOKEN into the curl -H argument before curl starts, which puts the bearer in the process command line visible to local process inspection/logging. That contradicts the runbook’s guarantee that the operator path never handles the bearer directly; use a brokered request or a mechanism that does not place the secret in argv.

Useful? React with 👍 / 👎.

-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.
73 changes: 73 additions & 0 deletions docs/registration/chittycommand-registration-payload.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
{
"registrationToken": "<<CHITTY_REGISTER_TOKEN>>",
"environment": "production",
"service": {
"chittyId": "<<PENDING_P_SYNTHETIC_CHITTYID>>",
"serviceName": "chittycommand",
"displayName": "ChittyCommand",
"description": "Sovereign meta-orchestrator and life management platform — ingests data from 15+ financial, legal, and administrative sources; scores urgency; enforces trust gates on intent execution; dispatches actions via registered executor registry, cluster daemon, and MCP server.",
"version": "0.1.0",
"baseUrl": "https://command.chitty.cc",
"endpoints": [
{ "path": "/health", "method": "GET", "description": "Real-dependency health probe (db + chittyconnect + daemon heartbeat)", "authenticated": false },
{ "path": "/api/v1/status", "method": "GET", "description": "Service metadata, tier, meta endpoint surface", "authenticated": false },
{ "path": "/api/v1/canon", "method": "GET", "description": "Canon info and registry status", "authenticated": false },
{ "path": "/api/v1/schema", "method": "GET", "description": "Lightweight schema references", "authenticated": false },
{ "path": "/api/v1/beacon", "method": "GET", "description": "Last beacon timestamp and status", "authenticated": false },
{ "path": "/api/v1/cert/verify", "method": "POST", "description": "Verify a ChittyCert certificate", "authenticated": false },
{ "path": "/api/v1/cert/:id", "method": "GET", "description": "Certificate details by ID", "authenticated": false },
{ "path": "/api/v1/whoami", "method": "GET", "description": "Identity: subject and scopes", "authenticated": true },
{ "path": "/api/v1/intents/:id/execute", "method": "POST", "description": "Atomic intent execution — claim, dispatch via executor registry, transition status", "authenticated": true },
{ "path": "/api/v1/context", "method": "GET", "description": "Get active persona, label, and tags", "authenticated": true },
{ "path": "/api/v1/context", "method": "POST", "description": "Set active persona, label, and tags", "authenticated": true },
{ "path": "/api/v1/connect/status", "method": "GET", "description": "ChittyConnect health", "authenticated": true },
{ "path": "/api/v1/connect/discover", "method": "POST", "description": "Resolve service URL via ChittyConnect", "authenticated": true },
{ "path": "/api/v1/ledger/evidence", "method": "GET", "description": "List evidence for a case via ChittyLedger", "authenticated": true },
{ "path": "/api/v1/ledger/record-custody", "method": "POST", "description": "Record custody entry for an evidence_id", "authenticated": true },
{ "path": "/api/v1/timeline/:caseId", "method": "GET", "description": "Unified case timeline (facts, deadlines, disputes, docs)", "authenticated": true },
{ "path": "/api/v1/litigation/synthesize", "method": "POST", "description": "AI fact synthesis from raw notes", "authenticated": true },
{ "path": "/api/v1/litigation/draft", "method": "POST", "description": "AI email drafting from synthesized facts", "authenticated": true },
{ "path": "/api/v1/litigation/qc", "method": "POST", "description": "AI risk scan of draft vs source notes", "authenticated": true },
Comment on lines +27 to +30

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Register the routes that actually exist

These /api/v1/... entries do not match the current Hono mounts I checked: timelineRoutes exposes /api/v1/cases/:caseId/timeline, while the litigation routes are mounted under /api/litigation/*, not /api/v1/litigation/*. Submitting this payload would advertise endpoints that return 404, which undermines the registration inventory and any registry endpoint verification based on it.

Useful? React with 👍 / 👎.

{ "path": "/api/v1/jobs", "method": "GET", "description": "Scrape job queue", "authenticated": true },
{ "path": "/api/v1/jobs", "method": "POST", "description": "Enqueue scrape job", "authenticated": true },
{ "path": "/api/v1/jobs/:id", "method": "GET", "description": "Scrape job details", "authenticated": true },
{ "path": "/api/v1/jobs/:id/retry", "method": "POST", "description": "Retry failed scrape job", "authenticated": true },
{ "path": "/api/v1/jobs/dead-letters", "method": "GET", "description": "Dead letter queue", "authenticated": true },
{ "path": "/api/dashboard/summary", "method": "GET", "description": "Dashboard summary with urgency scores", "authenticated": true },
{ "path": "/api/accounts", "method": "GET", "description": "Financial account list", "authenticated": true },
{ "path": "/api/accounts", "method": "POST", "description": "Create financial account", "authenticated": true },
{ "path": "/api/obligations", "method": "GET", "description": "Bills, debts, recurring obligations", "authenticated": true },
{ "path": "/api/obligations", "method": "POST", "description": "Create obligation", "authenticated": true },
{ "path": "/api/disputes", "method": "GET", "description": "Active dispute management", "authenticated": true },
{ "path": "/api/disputes", "method": "POST", "description": "Create dispute", "authenticated": true },
{ "path": "/api/recommendations", "method": "GET", "description": "AI action recommendations", "authenticated": true },
{ "path": "/api/cashflow", "method": "GET", "description": "Cash flow analysis and projections", "authenticated": true },
{ "path": "/api/sync", "method": "POST", "description": "Manual data sync trigger", "authenticated": true },
{ "path": "/api/bridge/*", "method": "GET", "description": "Inter-service bridge passthrough (read)", "authenticated": true },
{ "path": "/api/bridge/*", "method": "POST", "description": "Inter-service bridge passthrough (write)", "authenticated": true },
{ "path": "/mcp/*", "method": "POST", "description": "MCP server — 50 tools across 12 domains (service-auth)", "authenticated": true }
],
"healthCheck": { "path": "/health", "method": "GET", "expectedStatus": 200, "timeout": 5000 },
"category": "core-infrastructure",
"dependencies": [
"chittyauth","chittyid","chittycert","chittyconnect","chittyregistry","chittyschema","chittyrouter","chittyfinance","chittyscrape","chittyledger","chittyevidence","chittyassets","chittycharge","chittybooks","chittytrust","chittyagent-orchestrator","chittyagent-tasks","chittyagent-ch1tty","chittychat"
],
"capabilities": [
"intent-execution","executor-registry","sovereignty-gate","meta-orchestration","cluster-daemon","financial-ingest","legal-ingest","urgency-scoring","litigation-support","mcp-server","scrape-job-dispatch","document-storage","action-recommendations","bridge-api"
],
"certificationLevel": null,
"metadata": {
"canonicalUri": "chittycanon://core/services/chittycommand",
"tier": 2,
"tierSurface": "Tier 2 (Platform) with Tier-5 dashboard surface",
"domain": "command.chitty.cc",
"adrs": ["ADR-001"],
"executors": ["update_obligation_status"],
"clusterDaemonRegistration": "sub-channel via agent.chitty.cc/api/v1/channels — NOT in this payload",
"previousChittyId": "03-1-USA-3846-T-2602-0-57",
"previousChittyIdDeprecationReason": "T-type (Thing) encoding — invalid for a P-Synthetic sovereign actor",
"mcpToolCount": 50,
"mcpDomains": 12
}
}
}
Loading