docs: propose persistent Agent runtime lifecycle

[freeqaz-openai]

What Problem This Solves

A restart or accepted stop request does not establish safe continuation or physical termination. Operators need clear outcomes when retained files, helper processes or remote effects remain unresolved.

Why This Change Was Made

The current ordinary Kubernetes controller selects and requests activation of the successor before requesting predecessor retirement. That path does not yet establish observed predecessor termination and writer exclusion before successor writes. This proposal requires that contract and accepts the resulting availability gap. Managed reads, then approved publication, need this replacement discipline, root work and complete ownership of any supported helpers. Public Stop task / Stop Agent / Start Agent controls, completed-state recovery and broader durable Work and child coordination are later delivery stages.

User Impact

The proposed controls distinguish accepted intent, authority withdrawal, physical termination and credential cleanup. Recovery begins with compatible same-build, same-cluster retained storage; unknown creates or termination block writable replacement. Fresh execution rechecks current authority and preserves effect receipts without replaying uncertain operations. Execution may be uncapped; leases, operation deadlines and any selected drain or delivery remain finite. Public Stop defaults remain open.

This is a documentation proposal extending RFC 0027. It remains draft with a blank implementation issue pending acceptance.

Reading Guide

• Persistent Agent and runtime lifecycle and detailed specification.
• Related drafts: #68, #69, #70.

Evidence

• Checked draft metadata, required sections, Markdown structure, links, anchors and whitespace; reran desktop/mobile rendering and independent cross-RFC review.
• Desktop preview uses a local Markdown render with GitHub-style CSS.
• Document checks only; provider, native runtime and deployment qualification require separate evidence.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge. Reviewed September 14, 2026, 5:59 PM ET / 21:59 UTC (Revision 8).

ClawSweeper review

What this changes

Adds an illustrated proposal for safe Agent replacement, persistent stop intent, and staged recovery and completed-result delivery.

Merge readiness

⛔ Blocked before merge - 3 items remain

Keep open: the proposal contains substantive lifecycle contracts beyond accepted RFC 0027. No concrete patch defect was found, but repository policy requires design acceptance before merging a draft RFC.

Priority: P3
Reviewed head: 1b729a515b51be2619a3b7464462b71d47fd6160
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A coherent, illustrated proposal with no actionable patch findings; design acceptance remains separate from patch quality.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): The tracked desktop preview visibly demonstrates the changed RFC and lifecycle diagram. This is sufficient presentation evidence for the documentation proposal; runtime enforcement remains expressly unimplemented and unqualified.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): The tracked desktop preview visibly demonstrates the changed RFC and lifecycle diagram. This is sufficient presentation evidence for the documentation proposal; runtime enforcement remains expressly unimplemented and unqualified.
Evidence reviewed	8 items	RFC acceptance policy: README requires a maintainer-discussion thread and acceptance before merge, followed by accepted metadata and an implementation issue. The proposed RFC currently has draft status and a blank issue, appropriately indicating that acceptance remains pending. Distinct proposed scope: Read the complete proposal, 444-line supporting specification, diagram source, and both tracked images. Durable admission, recovery, and completed-result delivery extend the accepted deployment baseline; they are explicitly staged proposals rather than deployed guarantees. Accepted baseline and history: Current main already requires predecessor Harness termination before successor activation. Git blame, file history, and the patch against the commit's raw recorded parent locate this baseline in af708f0. GitHub confirms #35 merged that RFC; it does not establish implementation of this proposal's additional contracts.
Findings	None	None.
Security	None	None.

How this fits together

The proposed lifecycle belongs to the OpenClaw Enterprise controller, which turns authorized Agent configuration and control requests into runtime actions. Compute and sandbox drivers report execution and termination observations that govern replacement and recovery.

flowchart LR
  A[Authorized Agent intent] --> B[Enterprise controller]
  B --> C[Isolated candidate]
  B --> D[Retire predecessor]
  D --> E{Writers confirmed stopped?}
  E -->|No| F[Retain data and block replacement]
  E -->|Yes| G[Activate candidate and enable routing]
  C --> G

Loading

Decision needed

Question	Recommendation
Should RFC 0037 be accepted with mandatory initial runtime safety and separately selected later lifecycle and recovery profiles?	Accept the staged contract: Confirm the design in the required discussion, then record acceptance and link its implementation issue before merge.

Why: The repository explicitly reserves RFC acceptance for human design review; technical coherence and presentation proof cannot establish acceptance.

Before merge

• Resolve merge risk (P1) - The pinned external controller citations returned HTTP 404, leaving the description of deployed activation order independently unverified.
• Complete next step (P2) - Complete the required maintainer discussion and acceptance decision; if accepted, set status to accepted and link the implementation issue before merge.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Proposal scope	518 Markdown lines, 51 diagram-source lines, 2 PNG assets; production +0, tests +0	The branch expands the design specification without changing executable runtime behavior.

Merge-risk options

Maintainer options:

1. Decide the mitigation before merge
   Adopt a staged lifecycle contract that preserves observed writer exclusion while leaving public Stop defaults and optional recovery profiles to explicit later qualification.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Technical review

Best possible solution:

Adopt a staged lifecycle contract that preserves observed writer exclusion while leaving public Stop defaults and optional recovery profiles to explicit later qualification.

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

Not applicable: this PR proposes lifecycle contracts rather than repairing executable behavior; its presentation was inspected directly.

Is this the best way to solve the issue?

Yes, the staged RFC is a coherent extension of the accepted deployment contract, with runtime qualification explicitly separated from document acceptance.

AGENTS.md: not found in the target repository.

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

Labels

Label justifications:

• P3: This is a design-document proposal with no executable change or demonstrated urgent regression.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): The tracked desktop preview visibly demonstrates the changed RFC and lifecycle diagram. This is sufficient presentation evidence for the documentation proposal; runtime enforcement remains expressly unimplemented and unqualified.
• proof: sufficient: Contributor real behavior proof is sufficient. The tracked desktop preview visibly demonstrates the changed RFC and lifecycle diagram. This is sufficient presentation evidence for the documentation proposal; runtime enforcement remains expressly unimplemented and unqualified.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The tracked desktop preview visibly demonstrates the changed RFC and lifecycle diagram. This is sufficient presentation evidence for the documentation proposal; runtime enforcement remains expressly unimplemented and unqualified.

Evidence

What I checked:

• RFC acceptance policy: README requires a maintainer-discussion thread and acceptance before merge, followed by accepted metadata and an implementation issue. The proposed RFC currently has draft status and a blank issue, appropriately indicating that acceptance remains pending. (README.md:80, 967d9aac7472)
• Distinct proposed scope: Read the complete proposal, 444-line supporting specification, diagram source, and both tracked images. Durable admission, recovery, and completed-result delivery extend the accepted deployment baseline; they are explicitly staged proposals rather than deployed guarantees. (rfcs/0037/lifecycle-spec.md:19, 1b729a515b51)
• Accepted baseline and history: Current main already requires predecessor Harness termination before successor activation. Git blame, file history, and the patch against the commit's raw recorded parent locate this baseline in af708f0. GitHub confirms RFC 0027: OpenClaw as the Open Enterprise Agent Platform #35 merged that RFC; it does not establish implementation of this proposal's additional contracts. (rfcs/0027-openclaw-enterprise.md:417, af708f0ddb6f)
• Presentation proof inspected: The prepared download was HTML despite its PNG filename, so the actual tracked PNG was inspected directly. It visibly renders the current proposal, staged scope, replacement order, and stop/delivery illustration. This proves document presentation, not native runtime qualification. (rfcs/0037/review-preview.png, 1b729a515b51)
• Explicit external implementation claim: The proposal explicitly cites pinned Enterprise controller source for its description of current activation and retirement order. This establishes a relevant external-source dependency for that factual claim, but no dependency on the Codex runtime or harness. (rfcs/0037-persistent-agent-runtime-lifecycle.md:44, 1b729a515b51)
• External citation inspection limitation: GitHub reads of both cited paths in openclaw/openclaw-enterprise at 3eeacb85d9e8e087bc3e74d792778e4ef3123412 returned HTTP 404. Repository contents and ownership could not be independently verified through those requests; the claimed call order remains unverified, not disproved.

Likely related people:

• kevinlin-openai: Raw commit af708f0 adds rfcs/0027-openclaw-enterprise.md:417 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: af708f0ddb6f; files: rfcs/0027-openclaw-enterprise.md)

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 (7 earlier review cycles)

• reviewed 2026-09-08T22:14:47.312Z sha c7b5fe1 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-09T00:41:47.142Z sha b4147de :: needs real behavior proof before merge. :: none
• reviewed 2026-09-09T21:11:33.745Z sha 8a468b9 :: blocked before merge. :: none
• reviewed 2026-09-09T21:43:13.907Z sha 93b6115 :: blocked before merge. :: none
• reviewed 2026-09-11T07:48:37.665Z sha fe4ba21 :: blocked before merge. :: none
• reviewed 2026-09-11T19:09:23.070Z sha 144f276 :: blocked before merge. :: none
• reviewed 2026-09-11T19:30:52.898Z sha 1b729a5 :: blocked before merge. :: none