- cayceops core: env-only config (CAYCE_OPS_*), engine/session, ORM models with state machines (proposal/mail/content) and audited writes - provider-agnostic LLM interface (null provider default, stdlib openai-compat) - Typer CLI with lazy component loading (scanner/executor/maild/publisher/monitor) - alembic 0001 initial schema; sqlite-portable JSON columns - tests: 7 passing on throwaway sqlite; fixtures invented, never real data - ci: ruff + alembic smoke + pytest + gitleaks(full history) in .gitea/workflows + .github/workflows; local gate = make check - deploy: docker-compose (postgres 16) + hardened systemd units/timers - docs: DECISIONS D1-D9; README project (grant text retired)
3.8 KiB
Architectural decisions
Each entry: decision, why, and what it costs us. Newest last.
D1 — uv + uv.lock as the lockfile
uv manages the pinned interpreter (3.12) and produces uv.lock. CI installs
with uv sync --frozen; nothing runs against unpinned trees.
Cost: contributors need uv (single static binary).
D2 — Tests on SQLite; migrations authoritative for Postgres
Tests run on file-backed SQLite via metadata.create_all (fast, no service
dependency). The Alembic chain is the production schema path; make migrate-check (CI job) smoke-runs alembic upgrade head on SQLite.
Cost: Postgres-specific features (e.g. JSONB, partial indexes) stay unused —
the schema uses portable sa.JSON instead.
D3 — LLM behind an in-repo provider interface; null by default
cayceops.llm.LLMProvider is the only seam. null provider raises — components
fall back to deterministic rules. openai-compat uses stdlib urllib against
any OpenAI-shaped endpoint; no SDK dependency.
Cost: no retries/streaming/tool-calls — acceptable for classification and
draft drafting. Add providers by implementing complete().
D4 — Nostr client implemented in-repo (coincurve + websockets)
NIP-01 event build/sign/publish is ~150 auditable lines vs. a black-box SDK.
Keys accepted as 32-byte hex only. Relays are plain env config; publish is
fire-and-wait with a timeout; the event id is stored as post_ref.
Cost: no NIP-05, no retries across relay pools — fine for kind-1 notes.
D5 — AUTONOMOUS_MODE semantics (the only non-human approval path)
Default false: only human-approved proposals execute, only
human-approved drafts are sendable/publishable.
true adds exactly one capability: the executor may auto-approve
proposed items whose kind is in CAYCE_OPS_AUTONOMOUS_KINDS, up to
CAYCE_OPS_AUTONOMOUS_DAILY_CAP per day, recording actor auto:policy in the
audit log. Everything else still requires a human. Auto-approval never touches
mail drafts or content items.
Cost: two code paths; both audited; the autonomous one is off by default and
cap-bounded.
D6 — CI workflow files ship now; enforcement gate is make check until a runner exists
.gitea/workflows/ci.yml (Gitea Actions) and .github/workflows/ci.yml
(identical) run ruff, alembic smoke, pytest, gitleaks on every PR/push. The
current host runs no Gitea Actions runner, so until one is provisioned the
same gate is enforced locally: scripts/pre-push runs make check (lint +
tests + migration smoke + full-history secret scan) before every push, and the
audited commit hash in AUDIT.md is the one that passed it.
Cost: CI results are deferred on the current host; the gate itself is
identical to CI.
D7 — gitleaks allowlist for test fixtures
tests/ contains invented data (fake Nostr key, fake merchant mail). It is
allowlisted in .gitleaks.toml so the history scan stays signal-only.
Cost: a real secret committed under tests/ would not trip the scanner —
compensating control: fixtures are reviewed in PRs, and no fixture ever reads
the environment.
D8 — Proposal history kept when retiring the grant text
The repo began as a grant proposal; the retirement commit replaces it with the
project README (no grant references in the tree). The old commits stay — the
audit story ("this started as X, the operator mandated Y, here is the diff") is
more honest than a rewritten birth.
Cost: git log still shows the word "OpenSats" in old messages. The tree and
README carry none.
D9 — Executor plugins are in-process registrations
An action plugin is a Python function registered in
cayceops.components.executor.plugins.REGISTRY, mapped by proposal kind.
http_post exists but is inert unless CAYCE_OPS_ENABLE_HTTP_ACTIONS=true.
Cost: no sandboxing of plugins — plugins are repo code, reviewed like
everything else.