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
55 changes: 48 additions & 7 deletions CHARTER.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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 |
Expand Down Expand Up @@ -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 |
Expand All @@ -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

Expand All @@ -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*
12 changes: 9 additions & 3 deletions CHITTY.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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

Expand All @@ -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.
Expand Down Expand Up @@ -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

Expand Down
13 changes: 11 additions & 2 deletions CLAUDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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

Expand Down
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.

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 Pass jq variables with --arg before submission

If an operator follows the production instruction below to wrap this command under op run, this jq filter writes the literal strings $CHITTY_REGISTER_TOKEN and $NEW_CHITTYID into the JSON; shell variables are not expanded inside the single-quoted jq program, and jq --help shows --arg name value is the supported way to bind string values into $name. That means the registration payload would be submitted with the placeholder token/id rather than the minted P-Synthetic ChittyID, causing registration rejection or bad service metadata.

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" \
-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.
Loading
Loading