rig-lifecycle-d62939 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited rig-lifecycle-d62939 (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
The family of operations that create, start, stop, resume, restore, snapshot, release, unclaim, and destroy OpenRig-managed topologies. Includes the user story after reboot: "bring my work back without turning a clean recovery into a cleanup project."
If lifecycle is brittle, every higher-level primitive inherits that brittleness. Queue, workflow, seat continuity, cross-host operation, and RSI all assume that rigs and seats can be restored into known states.
rig up / down / restore / resume / snapshot / release / unclaim / destroyrig ps after a reboot or recovery and deciding what to trustresumed / rebuilt / fresh / failed / attention_required)openrig-user skill for CLI surfaceopenrig-operatoropenrig-architectFailed resume is FAILED loudly. No automatic fresh fallback. Fresh launch is explicit follow-up only. This is enforced architecturally at the daemon level (per docs/as-built/architecture/architecture-rules-and-event-system.md rule 15).
The locked restore-outcome vocabulary:
| Outcome | Meaning |
|---|---|
resumed | Native runtime resumed the same conversation |
rebuilt | New process assembled from artifacts (session_source: mode: rebuild) |
fresh | New process with no prior continuity |
failed | Restore attempted and failed; no automatic fallback |
attention_required | Recoverable blocker (provider auth refused, etc.); needs operator action |
n-a | Not applicable (terminal nodes, etc.) |
Codex auth-refusal returns attention_required (recoverable); Claude looksLikeClaudeLoginPrompt returns failed/login_required (terminal). Cross-runtime alignment is an open follow-up question.
Lifecycle proof should include real reboot or VM-reboot evidence, not only daemon-unit evidence. The minimum useful matrix covers:
| Scenario | What it proves |
|---|---|
| Clean start | Boot from spec into known state |
| Warm resume | rig down → rig up <name> resumes seats |
| Host reboot / tmux socket absence | Recovery from lost tmux connection |
| Provider auth loss | Codex/Claude auth refusal handled honestly |
| Partial boot / partial failure | Some seats up, some failed; honest reporting |
| Intentional operator recovery | Operator-initiated restore from snapshot |
Tier 1: in-process bedrock (daemon-unit evidence). Tier 2: real reboot or disposable Tart VM. Tier 1 alone is not lifecycle proof; it's bedrock.
Treat default policy as part of the primitive, not an afterthought. Lifecycle defaults that are too optimistic for the reliability level actually proven create silent harm:
auto-restore defaults that mask failure modesThe rail sequences restore truth into four rungs:
fully_restored is a Rung 3 execution rollupNaming discipline matters. "Fully restored" and "fully back" are different claims; don't conflate.
openrig-user skill — CLI surface for rig up / down / restore / etc.openrig-operator skill — operator-level discipline for OpenRig itselfseat-continuity-and-handover skill — occupant-creation modes for restore (resume / rebuild / fresh / failed)openrig/docs/as-built/architecture/lifecycle-snapshot-restore.md (product reference doc) — daemon enforcement of restore-honesty rule~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.