RFC 0013 addendum: application-consistent recovery for scale-to-zero

[giodl73-repo]

Summary

Scale-to-zero means OpenClaw can safely hibernate when idle and wake when work
arrives, so hosts do not pay for idle containers. Vincent's snapshot work gives
OpenClaw durable state capture and restore, while Peter's Gateway suspension
and Cron work provides much of the lifecycle foundation.

The remaining need is a small handoff with the host: remember that work is
waiting, wake a replacement, restore its accepted state, and wait until the
Gateway is ready before sending the queued work. This PR defines that
application-consistency contract without moving the host's scheduler,
transport, placement, or retained payloads into OpenClaw.

The detailed proposal adds three optional, host-neutral lifecycle
specifications to the completed RFC 0013 SQLite snapshot contract:

• recovery-point component composition;
• portable final handoff; and
• restored admission.

Together they define the application-consistency proof a host needs before it
can safely replace a Gateway generation or remove idle compute. They do not
define a new snapshot implementation, pause API, storage provider, or wake
system.

This PR is stacked on RFC PR #20.
RFC 0013 and
openclaw/openclaw#105718
remain authoritative for one-database SQLite snapshot creation, verification,
local publication, and fresh-target restore.

Why This Is Needed

Per-user and event-driven hosts can scale resident compute to zero only if they
can prove all of the following:

1. the retiring Gateway generation closed the complete owner-selected state;
2. the host durably accepted the exact required byte set;
3. source-compute retirement was authorized for that exact generation; and
4. replacement admission remained closed until the same recovery point and
   required owner state were restored.

A verified SQLite snapshot proves none of those aggregate lifecycle facts by
itself. Without a shared contract, hosts must either keep idle Gateways warm or
maintain private shutdown, copying, restore-ordering, and readiness-inference
paths.

The motivating managed-host deployment already has durable ingress and cron
wake machinery. Its production issue cluster includes accepted work outliving
the compute that should process it, cold-start head-of-line blocking, cron wake
racing idle retirement, scheduler continuity failing after replacement, and
cold runtimes appearing ready before the required owner state is restored.
OpenClaw's broader state-ownership risk is also tracked in
openclaw/openclaw#101290.
The complete user/operator case, including missed recurring work, competitor
scale-to-zero primitives, and Microsoft Scout's host-side composition, is
tracked in
openclaw/openclaw#114145.

Industry Baseline And OpenClaw's Missing Layer

Infrastructure and sandbox platforms already expose the compute primitives:

Platform	Primitive
Fly Machines	Traffic-driven stop-to-zero and autostart
E2B	Persistent pause and automatic resume
Daytona	Persistent stop/start, archive, and VM pause/resume
Azure Container Apps	Event-driven scale-to-zero
Cloudflare Durable Objects	Hibernation with wakeable WebSocket delivery

Those systems cannot infer OpenClaw's complete owner inventory, SQLite
invariants, scheduler state, or restored-readiness boundary. This addendum
defines that application-consistent layer. Retained ingress, wake registration,
compute placement, and external durability remain host responsibilities.

What Changed From The Earlier Continuity Direction

The sidecars compose contracts already shipped on OpenClaw main:

• openclaw backup sqlite from
  #105718; and
• gateway.suspend.prepare|status|resume from
  #103618, including
  Vincent's validation repair in
  #103925.

They replace the earlier broad continuity direction rather than adding another
SQLite capture path, Gateway pause API, provider framework, Lobster transport,
CAPE configuration surface, or Elastic wake mechanism.

The suspension contract remains a cooperative tracked-work fence, not full
process quiescence. The host still owns external ingress fencing, third-party
Channel transports, unregistered work, process supervision, encryption,
retention, placement, and wake.

Closed Boundaries

• The runtime state owner supplies a canonical required-component inventory;
  missing and extra components fail closed, and the inventory is covered by
  the recovery-point identity.
• Ordinary RFC 0013 snapshots remain host-protected. They cannot be called
  credential-free portable without exact owner-authored portability receipts.
• Obligations use a closed kind/owner/treatment vocabulary and contain no
  secret values.
• Host acceptance binds canonical aggregate-manifest bytes plus every exact
  owner-manifest and artifact byte sequence. Packaging and paths remain
  host-owned.
• Restored admission binds the same acceptance-set identity through hold,
  restored-start, and ready evidence. When RFC 0018 canonical readiness is
  available and enabled, it projects that same evidence without adding a
  second evaluator.
• Unknown outcomes hold or quarantine. Quarantine has no automatic exit.

The lifecycle facts are deliberately separate:

GatewaySuspensionReady
  -> SourceWritersClosed
  -> RecoveryPointCaptured
  -> RecoveryPointAccepted
  -> SourceComputeRetirementAuthorized
  -> RecoveryPointRestored
  -> AdmissionReady

There is no global /synced state. Each fact has a different owner, subject,
lifetime, and failure boundary. The diagram is the success path, not an
unconditional linear workflow: retained work may race retirement, atomically
revoking it while source compute exists or joining the destination wake after
retirement.

Observable Outcome Of The Complete Composition

• Idle resident compute may reach zero without treating raw live files as a
  recovery point.
• Accepted ingress remains retained until restored admission succeeds.
• Autonomous scheduled work can recover from absent compute without an
  unrelated user message.
• Source compute is never retired before exact durable acceptance.
• Replacement readiness identifies the accepted recovery point it restored.

These are system-level acceptance criteria. The three current OpenClaw PRs
prove only the owner-side recovery-point, final-capture, and restored-admission
slices; they do not claim to complete host acceptance, retained ingress, wake,
or source-compute retirement.

One Contract, Two Directions

The lifecycle can be presented as one bidirectional host/runtime contract
without putting host lifecycle authority in OpenClaw. OpenClaw supplies the
running-source suspension methods, offline final-capture and accepted-restore
operations, and the restored-readiness fact. The host supplies durable
acceptance, compute generations, retained wake, placement, and source-compute
retirement.

Quiesced
  -> RecoveryPointCaptured
  -> RecoveryPointAccepted
  -> generation-scoped SourceComputeRetirementAuthorized
  -> retained wake cause
  -> RecoveryPointRestored
  -> AdmissionReady
  -> owner delivery and acknowledgement

This is a protocol boundary, not a generic base class or new callback
framework. A host may compose it behind prepareHibernate,
ensureRuntimeReady, and inspectLifecycle, but those remain host operations.
The existing gateway.suspend.*, scheduler hooks, recovery operations, and
admission fence are reused.

The RFC now recommends one concrete missing seam:

gateway.restore.status({ restoreOperationId })
  -> { status: "not-restored" }
   | { status: "held", reason, retryAfterMs, ...restoreIdentities }
   | { status: "ready", ...restoreIdentities, schedulerIdentity,
       ownerReadinessIdentity, readinessIdentity }

This follows Peter's gateway.suspend.status pattern: closed Gateway Protocol
schemas, operator.read, stable operation identity, no mutation, exact replay,
and typed conflict behavior. It projects PR 112896's existing durable ready
record rather than adding another journal or state machine. Offline restore
and quarantine do not become invented live phases. The method remains callable
only through an authenticated pre-admission control path while ordinary work
is held. That path is a tracked, bounded, non-enrolling host probe: restart
still wins, and nodes, pairing, remote clients, presence-bearing sessions, and
ordinary RPCs remain fenced. There is no gateway.restore.admit; OpenClaw
computes readiness and opens its own admission.

When RFC 0018 is available and enabled, the same record also publishes a
required RecoveryPointRestored condition through /readyz, openclaw ready,
Status, and Gateway readiness RPC. Stable subject refs identify the destination
Gateway, restore operation, accepted recovery point, runtime generation,
scheduler reconciliation, and required state-owner roles; current IDs and
generations stay in RFC 0018's identity package. The generic readiness
projection and operation-fenced status method must report the same readiness
generation. Neither may infer restore success from process health or
database-open success. gateway.restore.status remains independently useful
when canonical readiness is disabled or has not landed.

Planned handoff may create a new recovery point only after Gateway suspension,
host-proven source-writer closure, final capture, and durable acceptance.
Forced source loss creates no clean-retirement fact and recovers from the last
previously accepted point under its declared RPO.

Implementation Evidence

• openclaw/openclaw#112385
  composes verified RFC 0013 snapshots into one deterministic host-protected
  recovery point and exact acceptance-byte inventory, using one canonical
  generation-bound state-owner inventory receipt across the stack.
• openclaw/openclaw#112865
  is the final-capture PR stacked on #112385. It binds
  host-supplied closure evidence, creates final owner snapshots, and durably
  replays one committed recovery point.
• openclaw/openclaw#112896
  is the restored-admission PR stacked on #112865. It restores an exact
  accepted recovery point to fresh paths and reuses Gateway work admission to
  remain closed until scheduler reconciliation and required-owner readiness
  produce one durable ready record. It now also implements the proposed
  read-only gateway.restore.status projection and its tracked local probe
  handshake as representative proof. The
  public Gateway Protocol addition remains an explicit owner-review decision
  before merge or ship.
• Fork-only Lobster drafts
  #39,
  #41,
  #42,
  #43, and
  #45,
  #46,
  #47, and
  #51 (Microsoft access
  required) demonstrate permanent cron projection, cancellation arbitration,
  Peter's shipped hook/proxy-pipe composition, and a default-off private
  Blob/per-user ECS/already-due sleep-veto boundary, followed by one permanent
  payload-free retained-wake authority that coalesces concurrent owner causes
  into an exact destination generation, production-backed metadata-only
  Teams/cron owner validation, and exact-readiness-gated per-cause delivery
  with durable crash replay.

The retained-wake drafts deliberately do not activate a production route or
cohort. Lobster still needs an owner-approved accepted-final-handoff lookup and
canonical mapping from opaque logical runtime identity to the Teams/cron
semantic owners before those call sites can be wired safely.

These PRs and fork drafts are non-normative feasibility and owner-review
evidence. None moves external ingress fencing, clean shutdown, host acceptance,
publication, wake, compute placement, or source-compute retirement into
OpenClaw.

If Vincent, Peter, Josh Lehman, or other maintainers prefer a smaller or
different implementation that meets the RFC and issue #114145 outcomes, please
use it. The fork stack is evidence for review, not a requirement to preserve
this exact decomposition.

Current Main Update

Recent owner work narrows the remaining integration:

• Peter's merged #118393
  keeps each unresolved Cron run visible to Gateway suspension through bounded
  shutdown.
• Peter's merged #117705
  removes most local startup tax from Gateway-backed agent turns.
• Vincent's #113306
  campaign has landed durable parent publication and pending-snapshot recovery;
  generic staging-cleanup ownership remains open.
• Vincent's open #117258
  adds per-owner isolation for post-commit auth snapshot publication.

These foundations improve shutdown accounting, cold-start cost, snapshot
durability, and owner-local reconciliation. They do not yet provide the
accepted-final-handoff lookup, retained Teams/API/Cron wake authority,
generation placement, or exact-readiness-gated delivery replay required for
scale-to-zero.

The OpenClaw implementation stack was rebuilt on current main and is
mergeable at 32809a14fc6 (#112385), 77e09a8f5c9 (#112865), and
247457d3544 (#112896). Cross-fork PRs cannot target fork-only parent branches,
so GitHub displays cumulative child diffs even though branch ancestry is
linear.

Repository review also raises one placement decision: keep these optional
lifecycle contracts under completed RFC 0013, or move them to a standalone
draft RFC. The branch now states that RFC 0013 remains authoritative only for
the completed SQLite artifact contract until maintainers settle that boundary.

Review Request

Please review the ownership split and public status method before the
implementation stack is promoted:

1. RFC 0013 remains the completed SQLite owner primitive.
2. Current-main gateway.suspend.* remains the cooperative pause primitive.
3. The state owner, not aggregate composition, supplies the complete selected
   agent inventory from the activation-pinned runtime and binds its revision to
   the source generation.
4. Ordinary snapshots remain host-protected; portability requires owner proof.
5. Acceptance binds a closed logical byte set without standardizing a storage
   container.
6. The host owns ingress fencing, suspension orchestration, clean shutdown,
   wake, and compute lifecycle; final capture only binds supplied closure
   evidence.
7. OpenClaw core owns recovery-journal schema, migration, corruption, repair,
   retention, and cleanup semantics; unknown journal state never falls back to
   ordinary startup.
8. When available and enabled, RFC 0018 owns the canonical current-readiness
   projection, while gateway.restore.status remains the independent exact
   operation-fenced observation seam.

[giodl73-repo]

Hey @vincentkoc — this is the small follow-on referenced from #20.

The review question is only the ownership split:

1. RFC 0013 and backup sqlite remain authoritative for each SQLite artifact.
2. gateway.suspend.* remains the cooperative tracked-work fence.
3. These sidecars add only aggregate recovery-point identity, durable handoff acceptance, and restored admission/replay above those shipped contracts.

We are holding implementation until that boundary is accepted. The earlier RFC 0021 / twelve-PR design is now retained only as evidence, not proposed as the path forward.

[giodl73-repo]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Review in progress
• Detail: The exact-review queue leased this run; Codex is reviewing the item.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/30010475441
• Updated: 2026-07-23T13:16:35.194Z

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed September 9, 2026, 8:55 AM ET / 12:55 UTC (Revision 77).

ClawSweeper review

What this changes

Adds three draft specifications for composing recovery artifacts, handing accepted state to a host, and withholding replacement Gateway work until restoration is ready.

Merge readiness

⛔ Blocked before merge - 6 items remain

The proposal remains distinct work absent from the default branch. The corrected stack resolves the previous base concern, while RFC placement, owner acceptance, and restored-Gateway proof remain unresolved.

Priority: P2
Reviewed head: 65d74e137db53e517b21fc17b63696fa082717e9
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The contract is coherent and backed by useful implementation evidence, but acceptance structure and runtime proof remain incomplete.
Proof confidence	🦐 gold shrimp (3/6)	Needs stronger real behavior proof before merge: Linked WSL evidence usefully exercises real SQLite capture, journaling, replay, and CLI output, but restored Gateway admission and gateway.restore.status are demonstrated through tests rather than a real held-to-ready run. The external-PR gate applies because the changed files are under rfcs/, outside the docs/ exception. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs stronger real behavior proof before merge: Linked WSL evidence usefully exercises real SQLite capture, journaling, replay, and CLI output, but restored Gateway admission and gateway.restore.status are demonstrated through tests rather than a real held-to-ready run. The external-PR gate applies because the changed files are under rfcs/, outside the docs/ exception. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	8 items	Verified introduced scope: The pinned base-to-head delta contains four Markdown files, with 1,411 additions and one deletion. Raw test-merge parents match the pinned stacked base followed by the exact PR head; its result changes those same four files. Default branch and canonical search: The default-branch tree contains neither RFC 0013 nor its three recovery specifications. GitHub lists the snapshot parent #20 as closed unmerged; the recovery, readiness, and deadline proposals found through the repository pull endpoint do not establish a merged replacement. The releases endpoint returned no releases. RFC lifecycle and routing history: README requires draft proposals to remain unmerged until acceptance and an implementation issue are recorded. Git history identifies the RFC-process change; GitHub maps its author to kevinslin and supplies the exact README patch. Local blame and historical blob inspection failed because required objects could not be retrieved, so they were not treated as successful provenance checks.
Findings	1 actionable finding	[P2] Separate the lifecycle proposal from the completed snapshot RFC
Security	None	None.

How this fits together

The proposed recovery contract connects OpenClaw’s SQLite snapshots and Gateway suspension to host-managed compute replacement. Verified owner state enters the handoff; generation-bound restoration and readiness determine when retained work may be delivered.

flowchart LR
  A[State owners] --> B[Verified recovery artifacts]
  C[Gateway suspension and writer closure] --> B
  B --> D[Host durable acceptance]
  D --> E[Source retirement and replacement]
  E --> F[Restore and owner readiness]
  F --> G[Admit retained work]

Loading

Decision needed

Question	Recommendation
Should these recovery contracts become a standalone RFC, or be accepted as an explicitly separate lifecycle addendum to RFC 0013?	Use a standalone RFC: Preserve the completed snapshot contract and give recovery lifecycle ownership, status-method acceptance, and implementation tracking their own RFC metadata.

Why: The contributor explicitly defers restructuring to maintainers, and placement determines how the completed snapshot contract remains distinguishable from unaccepted lifecycle and protocol commitments.

Before merge

• Add real behavior proof - Needs stronger real behavior proof before merge: Linked WSL evidence usefully exercises real SQLite capture, journaling, replay, and CLI output, but restored Gateway admission and gateway.restore.status are demonstrated through tests rather than a real held-to-ready run. The external-PR gate applies because the changed files are under rfcs/, outside the docs/ exception. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Separate the lifecycle proposal from the completed snapshot RFC (P2) - The prior placement concern remains unresolved: this insertion adds a new lifecycle proposal under a document whose metadata still marks the one-database snapshot contract completed. The disclaimer helps readers, but does not give the new contracts their own acceptance state or implementation tracking as required by README’s RFC lifecycle. Move them into a standalone draft RFC, or obtain an explicit maintainer-approved addendum structure with separate acceptance metadata before landing.
• Resolve merge risk (P1) - The proposal’s placement under a completed RFC and ownership of the inventory, recovery journal, and public status method remain unaccepted.
• Resolve merge risk (P1) - The parent RFC is closed unmerged, so the corrected stacked base still needs an agreed landing path to the default branch.
• Complete next step (P2) - Resolve the RFC placement and landing path, record contract-owner acceptance, and add restored-Gateway runtime proof or an explicit proof override. Terminal output, logs, or a recording with diagnostics count; redact credentials, IP addresses, private endpoints, and other private data. Update the PR body to trigger re-review, or ask a maintainer to comment @clawsweeper re-review.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Findings

• [P2] Separate the lifecycle proposal from the completed snapshot RFC — rfcs/0013-cloud-serializable-sqlite-state.md:175-180

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Specification scope	4 Markdown files; +1,411 / -1 lines; production 0, tests 0	The substantial growth defines three proposed contracts without adding executable implementation.

Merge-risk options

Maintainer options:

1. Decide the mitigation before merge
   Give the lifecycle contract its own acceptance boundary, preferably a standalone draft RFC, while preserving SQLite snapshot semantics and requiring explicit Gateway and state-owner approval.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Technical review

Best possible solution:

Give the lifecycle contract its own acceptance boundary, preferably a standalone draft RFC, while preserving SQLite snapshot semantics and requiring explicit Gateway and state-owner approval.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this PR proposes recovery contracts rather than reproducing a current repository bug; its implementation evidence is assessed separately.

Is this the best way to solve the issue?

Unclear: composing existing snapshot and suspension primitives is coherent, but maintainers must accept the new ownership and status-method contract and resolve its RFC lifecycle placement.

Full review comments:

• [P2] Separate the lifecycle proposal from the completed snapshot RFC — rfcs/0013-cloud-serializable-sqlite-state.md:175-180
  The prior placement concern remains unresolved: this insertion adds a new lifecycle proposal under a document whose metadata still marks the one-database snapshot contract completed. The disclaimer helps readers, but does not give the new contracts their own acceptance state or implementation tracking as required by README’s RFC lifecycle. Move them into a standalone draft RFC, or obtain an explicit maintainer-approved addendum structure with separate acceptance metadata before landing.
  Confidence: 0.88

Overall correctness: patch is incorrect
Overall confidence: 0.88

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning medium; reviewed against 967d9aac7472.

Labels

Label justifications:

• P2: This is a concrete recovery-contract proposal with bounded owner decisions, rather than an urgent runtime regression.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: Linked WSL evidence usefully exercises real SQLite capture, journaling, replay, and CLI output, but restored Gateway admission and gateway.restore.status are demonstrated through tests rather than a real held-to-ready run. The external-PR gate applies because the changed files are under rfcs/, outside the docs/ exception. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

What I checked:

• Verified introduced scope: The pinned base-to-head delta contains four Markdown files, with 1,411 additions and one deletion. Raw test-merge parents match the pinned stacked base followed by the exact PR head; its result changes those same four files. (65d74e137db5)
• Default branch and canonical search: The default-branch tree contains neither RFC 0013 nor its three recovery specifications. GitHub lists the snapshot parent RFC 0013: SQLite snapshot backup artifacts #20 as closed unmerged; the recovery, readiness, and deadline proposals found through the repository pull endpoint do not establish a merged replacement. The releases endpoint returned no releases. (967d9aac7472)
• RFC lifecycle and routing history: README requires draft proposals to remain unmerged until acceptance and an implementation issue are recorded. Git history identifies the RFC-process change; GitHub maps its author to kevinslin and supplies the exact README patch. Local blame and historical blob inspection failed because required objects could not be retrieved, so they were not treated as successful provenance checks. (README.md:88, e366ea9825a4)
• Prior placement concern remains explicit: The proposal acknowledges that standalone-RFC placement remains undecided and limits the completed RFC’s authority to SQLite artifacts. The contributor’s latest comment confirms that restructuring awaits that decision. The earlier reviewed SHA was unavailable locally, so no patch-equivalence or late-finding claim is made. (rfcs/0013-cloud-serializable-sqlite-state.md:370, 65d74e137db5)
• Complete captured body inspected: The full GitHub body was read and its SHA-256 matched the supplied snapshot identity b4e614e2988ba1d9be82460cacb1d6136dd47a67874827d8fe3b085fa8b4618f. This recovered the omitted ranges without substituting a different body. The body explicitly links OpenClaw implementation evidence and retains owner approval of the public status method. (65d74e137db5)
• Useful real capture evidence: feat(snapshot): capture final recovery points openclaw#112865 records Ubuntu WSL execution using real SQLite owner databases, the production snapshot provider and recovery journal, and a real CLI subprocess. Reported observations include committed-result replay and tamper rejection; host-supervised shutdown and full live-host capture are expressly excluded. (77e09a8f5c94)

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Resolve RFC placement and record owner acceptance of the inventory, recovery journal, and public status method.
• Provide a redacted real restored-Gateway transcript showing exact recovery identity and held-to-ready admission, or obtain an explicit proof override for this design-only review.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (76 earlier review cycles; latest 8 shown)

• reviewed 2026-08-09T22:01:16.756Z sha 2f290e9 :: needs real behavior proof before merge. :: [P2] Move the lifecycle contract into a standalone draft RFC
• reviewed 2026-08-09T23:10:26.171Z sha 2f290e9 :: needs real behavior proof before merge. :: [P2] Move the lifecycle contract into a standalone draft RFC
• reviewed 2026-08-12T01:54:31.313Z sha 2f290e9 :: needs real behavior proof before merge. :: [P2] Separate the lifecycle contract into a draft RFC
• reviewed 2026-08-13T02:43:44.174Z sha 540fb7c :: needs real behavior proof before merge. :: [P2] Move the lifecycle contract into a standalone draft RFC
• reviewed 2026-08-14T01:30:24.697Z sha 2a70d5c :: needs real behavior proof before merge. :: [P2] Move the lifecycle contract into a standalone draft RFC
• reviewed 2026-08-15T11:06:29.372Z sha 2a70d5c :: needs real behavior proof before merge. :: [P2] Move the lifecycle contract into a standalone draft RFC
• reviewed 2026-08-15T13:57:36.584Z sha 2a70d5c :: needs real behavior proof before merge. :: [P2] Move the lifecycle contract into a standalone draft RFC
• reviewed 2026-09-09T05:30:39.340Z sha 026f6d8 :: needs real behavior proof before merge. :: [P2] Separate the lifecycle proposal from the completed snapshot RFC

[giodl73-repo]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Review in progress
• Detail: The exact-review queue leased this run; Codex is reviewing the item.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/30525032804
• Updated: 2026-07-30T08:02:30.209Z

[giodl73-repo]

Corrected the refresh at 65d74e1 after confirming this PR targets the stacked rfc/cloud-serializable-sqlite-state branch, not main. Only the 28 addendum commits are replayed on the exact live base 864d7de; range-diff is patch-equivalent and git diff --check passes. The standalone-RFC boundary remains a maintainer design decision. @clawsweeper re-review