108 lines
3.6 KiB
Markdown
108 lines
3.6 KiB
Markdown
---
|
|
domain: custodian
|
|
repo: the-custodian
|
|
updated: "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:
|
|
|
|
1. **What matters?** Values, constitution, charters, and governance constraints.
|
|
2. **What is being pursued?** Workplans, domain roadmaps, and coordination notes.
|
|
3. **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.
|
|
|