ADR-0002 — Server-anchored core, local shell for hardware-bound work
The core is anchored on an always-on server; a local shell handles work that needs local hardware.
Status: Accepted
Context
ADR-0001 establishes one core behind many shells but does not say where the core runs. Two forces pull in opposite directions. Some responsibilities want to run continuously — memory, the session registry, the self-improvement machinery, scheduled monitoring — and cannot depend on any one workstation being awake. Other responsibilities are hardware-bound — local filesystem editing, IDE integration, and channels that require a locally-authenticated session — and cannot run anywhere but the local machine.
Decision
Anchor the core on an always-on server, reachable only over a private internal network, and keep a local shell for the hardware-bound work. The server hosts the memory gateway, the session registry, the heavier self-improvement pipeline, and the scheduled jobs that must survive the workstation being off. The local shell provides filesystem access, IDE integration, and locally-authenticated channels — and consumes the core over the same internal API every other shell uses.
Concrete coordinates — hosts, ports, service names, filesystem paths — are deployment details, deliberately not part of the architecture and deliberately withheld from public documentation.
Consequences
- Positive: Continuous responsibilities genuinely run 24/7; the system keeps consolidating memory, monitoring, and improving itself while every workstation is asleep.
- Positive: Hardware-bound work still has a home, without dragging the whole core onto a machine that is not always on.
- Positive: Because both doors reach the same core over the same API, neither is privileged — work started on one is visible to and resumable by the other.
- Negative / accepted: Two substrates must be kept in parity — the vault and the skill set both need synchronisation so the doors do not drift. This is handled by dedicated synchronisation jobs and verified by reconciliation, which is an ongoing operational cost accepted in exchange for always-on capability.
- Negative / accepted: The private-network requirement is a real constraint on how the core is reached, accepted as a security property rather than a limitation.