Skip to content

Derive runtime storage from a single Push home #165

Description

@owainlewis

Goal

Give every Push installation one predictable runtime root while preserving the separate, user-owned assistant repository.

Scope

  • Introduce one typed runtime-path owner used by configuration, startup, jobs, history, audit, channels, tests, and service examples.
  • Resolve the runtime root from PUSH_HOME, defaulting to ~/.push.
  • Derive the default config, database, state, audit, run-lock, inbox, and cache locations from that root.
  • Keep assistant_root independently configurable and outside the runtime root's protected state boundary.
  • Preserve existing explicit state_path, database_path, audit_log_path, and jobs_run_dir configurations during a documented compatibility period.
  • Define and test precedence between --config, PUSH_HOME, explicit path settings, and defaults.
  • Keep multiple installations possible by assigning different PUSH_HOME values.
  • Update installation, service, configuration, security, and recovery documentation.

Non-goals

  • Do not move the assistant repository under the runtime root.
  • Do not change the contents or schema of persisted state.
  • Do not add a UI or network listener.

Acceptance criteria

  • A default installation resolves all Push-owned runtime files beneath ~/.push.
  • Setting PUSH_HOME relocates every derived runtime path consistently.
  • Existing installations with explicit path settings continue to start without data loss.
  • Unsafe overlap with the assistant repository still fails closed with an actionable error.
  • The resolved paths are owned by one reusable type rather than reconstructed across modules.
  • Tests cover default resolution, environment override, explicit overrides, missing HOME, unsafe overlap, and two isolated homes.
  • Documentation and service examples describe the single-root model.

Verify

  • cargo fmt --all -- --check
  • cargo clippy --locked --all-targets -- -D warnings
  • cargo build --locked
  • cargo test --locked

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent-readyScoped enough for an agent to pick upenhancementNew feature or requesthardeningRobustness / correctness

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions