3.6 KiB
domain, repo, updated
| domain | repo | updated |
|---|---|---|
| custodian | the-custodian | 2026-05-17 |
INTENT
This file explains why the-custodian exists, what role it plays in the ecosystem, and what it must not absorb as neighboring repositories mature.
Why it exists
The Custodian exists to hold the long-lived governance, memory, and coordination substrate for a local-first agent ecosystem spanning multiple project domains. It gives Bernd and trusted agents a stable place to preserve values, constitution, domain charters, workplans, and cross-domain orientation without turning any single implementation service into the source of identity.
Its deeper purpose is stewardship: keeping the system coherent across years of tool changes, repo splits, agent sessions, and domain growth.
The governing principle
the-custodian owns meaning, boundaries, and continuity.
It should answer:
- What matters? Values, constitution, charters, and governance constraints.
- What is being pursued? Workplans, domain roadmaps, and coordination notes.
- What must be remembered? Append-only memory, decisions, provenance, and session handoff context.
It should not become the implementation home for every service it coordinates. When a subsystem becomes operational code with its own runtime, tests, and deployment surface, it should live in its own repository and report back through State Hub and workplans.
What it is
the-custodian is the governance and continuity substrate for the Custodian ecosystem.
It contains:
- canon: constitution, foundational values, standards, domain charters, concept seeds, and roadmaps
- memory: working notes and episodic logs that preserve session continuity
- workplans: repo-backed plans for Custodian-owned coordination work
- runtime scaffolding: agent policies, prompts, and integration guidance
- integration pointers: lightweight references to operational services such as the standalone State Hub
What it is not
| Concern | Owner |
|---|---|
| Live State Hub implementation, migrations, dashboard, tests | state-hub |
| Event-triggered maintenance task creation | activity-core |
| General task lifecycle backend | issue-core |
| Repository capability profiling | repo-scoping |
| Domain-specific products and experiments | Their domain repositories |
| External publication, contracts, payments, or legal authority | Human approval only |
The repository may describe or coordinate these systems, but it should avoid reabsorbing their runtime code.
What it enables
When this repository is doing its job, a human or agent can:
- understand the purpose and rules of the whole ecosystem without reading every implementation repo
- start a session with clear governance and State Hub handoff rules
- trace work from values and domain charters into active workplans
- preserve decisions, provenance, and memory in durable, reviewable files
- split operational subsystems into focused repos without losing continuity
Design values
Local-first continuity. The core governance record must remain useful even when services are offline or external vendors change.
Human-approved authority. The Custodian can draft, coordinate, and remember, but irreversible decisions remain human-gated.
Small operational surface. This repo may coordinate services, but live services should own their own code, tests, and deployment paths.
Append-only memory by default. Session and episodic records should be preserved rather than silently rewritten.
Reviewable canon. Canon changes should be proposed with provenance and review, not silently applied as operational side effects.