Operator runbook

Native quality analysis is explicitly configured, never installed on invocation. Use qualification, opt-in configuration and evidence limits before enabling its optional actions/tools.

For the normal objective → work → outcome journey, start with the overview and work tour. Use this runbook when commissioning, deliberate control or a problem calls for an operation—not as a required checklist for every agent turn.

Choose the operation from the observed need. Do not start with repair/reset when you need ordinary control or clearer evidence. The runbook owns procedures; system requirements, operator contracts and architecture explain their contracts and owners. Project policy remains in AGENTS.md.

Choose the safe next task

I need to…	Start here	Decision boundary
Try Saivage on a fresh isolated target	Getting started	Init/provider setup/server start/objective/Run are distinct
Build/install/start an identified service	Deployment	Deployment-owned isolation/auth; verify exact release/project/owner
Configure routes, workflows, records or prompts	Configuration, stopped input adoption	No live reload or implicit identity upgrade
Pause, resume, stop or start project work	Runtime control	Pause gates providers; Stop contains card work, not server/listeners
Verify a lifecycle owner or abandoned lock	Ownership outcomes	Only verified live delegates; no automatic removal/takeover
Replace the server process	Confirmed restart	Separate bearer-authenticated confirmation; acknowledgement is not boot proof
Explain a startup/API/provider/context failure	Diagnosis	Read exact evidence, preserve unknowns; no blind retry or reset
Connect an external client directly to Analyst	Inbound MCP	Startup flags/independent secret/project-bound loopback handshake
Give Saivage tools from another MCP server	Outbound MCP	YAML/dynamic connection plus separate grants/discovered identities
Prepare native observation of approved source roots	Observed collections	Offline prepare; separate adoption starts native watchers, no manual indexes or universal embeddings
Inspect records, instructions, executions, output or images	Evidence	Current observation, retained provenance and provider perception differ
Reclaim unreferenced ordinary work	Explicit work GC	Preview first; separate fresh delete, private live-owner hold, irreversible effects
Repair damaged current-format selected state	Exact-target repair	Stopped/excluded, complete fresh backup, report and exact typed consent
Adopt incompatible formats/participating identities	Adoption decision	Remain stopped; explicit reset or owner-requested external migration
Intentionally discard generated history	Destructive reset	Concrete loss consent and complete stopped backup; four roots only
Preserve retained history across an incompatible release	External offline migration	Explicit identified-project request, independent complete candidate, strict validation/fidelity
Handle publication uncertainty	Stop on uncertainty	No follow-up read/write/retry/inspection/cleanup

Common prerequisites

• Identify exact project, service/process, release, selected inputs and operation authorization. Historical deployment notes do not identify today's owner or grant permission. Deployment boundaries separate target/release/container/network responsibilities.
• Preserve external authentication and outbound confidentiality. No tokens in URLs, no provider-config/credential/transcript dumps, no assumption the public UI/docs grants protected API access. Authentication supplies private browser setup despite the UI's no-login boundary.
• Offline mutation requires positive owner exclusion and successful complete preserved backup, not just a stopped unit or an existing archive. Follow offline prerequisites, then the selected procedure's additional consent/effect rules.
• Runtime accepts only its exact current contracts. The durable format reference is source evidence, not installation inventory, whole-project compatibility or adoption consent. Harmless noncanonical files stay ignored; never scan/clean/adopt orphans.

Command and location reference

Run target-local commands from the exact project root with the identified release.

Task	Command/location
Fresh init	saivage init [--profile classic|classic-typed|paad-typed]
Start server	saivage start --project-root <absolute-root> --config <absolute-yaml> --host <host> --port <port>
Read/control live runtime	saivage status, pause, resume, stop
Confirm server restart	saivage restart_server (bearer mode only)
Preview optional work reclamation	saivage gc-work --dry-run (use the full procedure before --delete)
Public health	/health, /health/ready
Public web/docs	/, /docs/ (/docs redirects)
Selected default YAML	.saivage/saivage.yaml
Lifecycle exclusion	.saivage/locks/runtime.lock (not reset-owned)
Reset-owned generated roots	.saivage/cards, .saivage/agents, .saivage/logs, .saivage/work

The command-selection matrix distinguishes Start, exact-cwd offline commands and ancestor-selected controls. Do not execute repair/reset/migration from a quick command table: use their complete procedures. Starting/restarting a server does not Run a project; an explicit Run does not authorize deployment, repair or data loss.