Skip to content

Durable Governed Proposal and Bounded Mutation

Operational boundary

AncientOS exposes one mutation capability: deterministic UTF-8 text replacement inside an explicitly configured disposable workspace. It cannot execute shell commands, modify repository source implicitly, traverse paths, follow symlinks, access the network, control Docker, or select additional targets.

The capability is disabled unless both settings are present:

  • LUNA_GOVERNED_FILE_PATCH_ENABLED=true
  • LUNA_GOVERNED_WORKSPACE=<absolute disposable workspace>

Containers use /data/governed_workspace as the configured workspace, but the executor remains disabled by default. Proposal, approval, evidence, and receipt tables use LUNA_GOVERNED_STATE_DB_PATH, which defaults to the same durable SQLite database as Kernel Records. These are separate tables and authorities; proposals are not stored only in Kernel Record payloads and are not LifeVault memory.

Lifecycle

operator proposal request
  -> deterministic path and content precondition inspection
  -> immutable proposal content and SHA-256 hash
  -> durable Zeus before-evidence
  -> durable Lich approval requirement
  -> awaiting_approval

explicit approval
  -> verify scope and proposal hash binding
  -> durable Lich decision
  -> approved_not_executed

separate execution request
  -> validate proposal, approval, expiry, freshness, path, hash, and stores
  -> execution_in_progress persisted as concurrency lock
  -> durable Zeus before-evidence
  -> atomic exact replacement
  -> validate exact post-state
  -> durable Zeus after-evidence and receipt
  -> rollback_available

explicit rollback request
  -> new durable Lich approval requirement
  -> explicit rollback approval (no mutation)
  -> separate rollback execution request
  -> post-state hash validation and atomic prior-content restoration
  -> durable Zeus evidence and rollback receipt
  -> rolled_back

Approval never executes. A rejected, expired, stale, out-of-scope, tampered, or unapproved proposal cannot enter execution. Lifecycle writes use optimistic revision checks. The original mutation content is immutable; lifecycle fields are excluded from the proposal content hash.

Durable schema

The idempotent migrations are:

  • 0002_durable_lich_approvals
  • 0003_governed_actions

The schema contains independently queryable lich_approvals, governed_proposals, governed_evidence, and governed_action_receipts tables. Indexed retrieval covers proposal/session scope, Lich proposal and operator scope, evidence order, and receipt order. Terminal proposals expire from retention after 90 days by default; active pending, approved, executing, and rollback-available records are not deleted by ordinary cleanup. The default terminal-record bound is 500.

File safety and failure semantics

The executor accepts only an existing regular file below the resolved workspace root. It rejects symlinks, traversal, non-regular files, invalid UTF-8, and files larger than 64 KiB. The old text must occur exactly once. Writes use a temporary file in the target directory, fsync, permission preservation, and atomic replacement.

Execution requires the current byte hash to equal the proposal precondition. Any mismatch marks the proposal stale rather than adapting the patch. If receipt persistence fails after replacement, AncientOS attempts immediate exact content compensation and records an execution failure. A failure is never presented as a durable success.

Operator prompts

  • Create a proposal to change file demo/config.txt from “mode=old” to “mode=new”.
  • Show pending proposals.
  • Show approved but unexecuted proposals.
  • Show my proposals.
  • Show proposal <proposal-id>.
  • Explain proposal <proposal-id>.
  • Validate proposal <proposal-id>.
  • Approve proposal <proposal-id>.
  • Reject proposal <proposal-id> because <reason>.
  • Execute approved proposal <proposal-id>.
  • Request rollback for proposal <proposal-id>.
  • Approve rollback for proposal <proposal-id>.
  • Execute rollback for proposal <proposal-id>.
  • Show runtime composition.

All commands enter the shared runtime pipeline, so terminal, Discord, and web TUI share lifecycle semantics. No transport callback owns mutation authority.

Validate proposal <proposal-id> is an Oracle read-only preflight over the live governed-action record. It does not copy the record into Oracle storage or convert it into Oracle's canonical proposal model. Oracle renders the current lifecycle, Lich binding, evidence freshness, executor configuration, target precondition, and blockers returned by the same pure preflight function that the executor reruns immediately before mutation. A passing result is point-in-time evidence only: it does not approve, authorize, reserve, execute, or guarantee future executability.

Known limitations

  • Operator identity is the current transport author plus conversation scope, not a general multi-user role system.
  • The first proposal builder is deterministic text replacement, not a general patch language or model-generated editor.
  • Rubick does not currently publish a first-class bounded file-patch capability record. Runtime Composition reports the injected executor lane honestly; Oracle validation does not infer or promote Rubick readiness from that fact.
  • Revocation and supersession are not exposed in this milestone; rejection is terminal and changed work requires a new proposal.
  • There is no scheduler. Expiry is enforced on retrieval, approval, and execution paths.
  • SQLite durability depends on preservation of the configured /data volume.
  • Zeus evidence is canonical and durable for this capability, but there is no general shared Zeus service for every AncientOS domain.
  • Lich approval durability is proven for this shared runtime store; unrelated application-specific confirmation systems retain their existing semantics.
  • Kernel Records link proposal lifecycle events, while the proposal/evidence/ receipt stores remain the authoritative detailed records.