TacidOS
Developers
Documentation

Decision 0014

The agent may rebuild its own source within a signed core; proposals, not pull requests

Architecture decision record 0014: The agent may rebuild its own source within a signed core; proposals, not pull requests

Status
Accepted
Date
2026-09-03

Context

The maintainer’s requirement: the system is self-improving and can commit updates from inside itself. The review’s objection: the immune system and the stem live in the very source the agent edits, and a maintainer drowning in agent pull requests is a maintainer who stops reading them.

The three plans

  • Grok: the agent may open PRs against /etc/tacid; a fine-tuned tool-use model published later.
  • Fable: agent edits are confined to agent.nix; tacid update pulls upstream.
  • Codex: “agent-generated but reviewable” definitions as a long-term direction; supply-chain trust matters more for an agent OS.

Decision

Tacid’s source is an input of every genome. At level 3 or higher the agent may check out tacidos, change it, run the tests, build this machine with --override-input tacidos ./checkout, switch and verify. Crates are partitioned: core (tacid-stem, tacid-keeper, tacid-protocol, the health gate) is channel-signed, verified by the keeper before activation, and replaceable only by the owner; everything else is agent-mutable. A self-built machine is marked and cannot claim stable.

The health gate named in that sentence is tacid-doctor reading tacid-facts, and for a long time both were on the mutable list — so the list contradicted this record, and three core crates were compiled out of code the agent could rewrite. ADR-0081 moves them and adds the test that would have caught it: a partition that classifies files promises something about processes, and the arrow between them has to be checked.

The agent never opens pull requests. It files proposals (branch, CI results, evaluation results, plain-language rationale) into the owner’s queue; the owner reviews, signs (Developer Certificate of Origin) and pushes. Species evolution: proposal → maintainer → CI → channel → every body. Hardware quirks found on one machine become proposals for nix/hardware/. Boards that cannot build Tacid use a workstation body as a remote builder.

Consequences

  • The daemon could not have written into its own source copy. /var/lib/tacid/source is where a machine keeps the Tacid it might improve, and filing a proposal is git checkout -b, git add and git commit in it — but the daemon’s unit is ProtectSystem = strict with StateDirectory covering memory and cache and not source, so /var/lib was read-only underneath it. The first proposal any machine ever filed would have failed on the branch. Nothing had noticed because nothing puts a source copy there yet: the daemon offers the proposal tools only when source/.git exists, so the trap was set for whoever first gave a machine its own source. The directory is declared now, and a static test reads the constants a binary names and the StateDirectory its unit declares and refuses a path that is in one and not the other.

  • “Tacid on Tacid” development from Phase 1.

  • The maintainer remains the selection pressure and is not buried.

  • Core changes always carry a human signature and two reviews (GOVERNANCE.md).

Alternatives rejected

  • The agent pushes to main: the species has no immune system.
  • No self-modification: contradicts the vision and wastes the best contributor the project has.