Skip to content

Governed atomic file rename

Status: implemented Era 8 capability, default disabled.

Capability contract

  • Capability ID: governed_atomic_file_rename
  • Operator outcome: rename one regular file between two registered paths in a disposable governed workspace without supplying a path or command.
  • Read-only operation: Oracle, inspect rename target <target-id>.
  • Mutation operation: Oracle, propose rename <target-id>.
  • Target identity: RenameTargetRegistry, populated from LUNA_GOVERNED_RENAME_TARGETS.
  • Source of truth: current source path, destination absence, content hash, inode, device, and the immutable registry entry.
  • Proposal type: existing durable GovernedProposal with an immutable atomic_rename_no_replace action reference.
  • Approval authority: Lich, bound to the exact proposal hash and scope.
  • Validation authority: rename-specific canonical preflight over lifecycle, expiry, evidence freshness, approval, registry identity, paths, hash, inode, destination absence, parent safety, and same-filesystem state.
  • Execution authority: Linux renameat2(RENAME_NOREPLACE) only.
  • Evidence: metadata-only Zeus evidence containing path, size, and content hash; file content is represented as [binary-content-redacted].
  • Receipt: durable execution and rollback receipts in the existing governed action store.
  • Rollback: exact reverse no-replace rename after a separate Lich approval.
  • Restart behavior: proposal, approval, evidence, receipt, and lifecycle survive service reconstruction; no service restart is performed.
  • Oracle commands: inspect, propose, queue, validate, apply, audit, and separately approved rollback through the shared runtime.
  • Transport path: the shared Runtime Kernel; no transport-specific mutation.
  • Rubick posture: implemented and wired, but execution ready only with the dedicated gate, explicit target registry, workspace, durable store, and request-time filesystem evidence.
  • Meepo transitions: unchanged; existing proposal lifecycle transitions apply.
  • Persistence: existing SQLite proposal, Lich, Zeus, and receipt authorities.
  • Known limitations: Linux no-replace primitive; regular files only; bounded file size; same filesystem; destination must not exist; no overwrite, directory, symlink, glob, copy, delete, or cross-device fallback.

Runtime configuration

LUNA_GOVERNED_FILE_PATCH_ENABLED=true
LUNA_GOVERNED_ATOMIC_RENAME_ENABLED=true
LUNA_GOVERNED_WORKSPACE=/data/governed_workspace

LUNA_GOVERNED_RENAME_TARGETS is an explicit JSON list:

{
  "target_id": "demo.report",
  "component": "demo",
  "label": "Demo report",
  "source_relative": "inbox/report.bin",
  "destination_relative": "archive/report.bin"
}

Neither source nor destination is accepted from operator prose. Parent symlinks, traversal, missing source, existing destination, changed inode or content, and cross-device placement fail closed.

Operator workflow

Oracle, inspect rename target demo.report.
Oracle, propose rename demo.report.
Oracle, show my action queue.
Oracle, validate proposal <proposal-id>.
Approve proposal <proposal-id>.
Oracle, apply approved proposal <proposal-id>.
Oracle, audit proposal <proposal-id>.
Request rollback for proposal <proposal-id>.
Approve rollback for proposal <proposal-id>.
Execute rollback for proposal <proposal-id>.

Approval, execution, rollback approval, and rollback execution remain separate requests. If durable after-evidence or receipt persistence fails after the atomic filesystem operation, the lifecycle records an execution failure and requires manual inspection; it never retries blindly or overwrites a target.