docs: propose service-owned work authority

[freeqaz-openai]

What Problem This Solves

An Agent’s work can outlast a turn, coordinator process or provider token. Shared Agents need lasting scope and cancellation ownership while keeping requester, service-owner and workload permissions separate.

Why This Change Was Made

Define an initial root work record with requester attribution, immutable scope and any configured horizon, cancellation, execution assignment and effect receipts. Subordinate helpers share its scope, resource limits and stop ownership. This supports managed reads and subsequent approved publication without gating them on a complete public Work API. Separately admitted durable children, broader Work management and public lifecycle controls follow later, with preserved lineage and ancestor constraints.

User Impact

Execution defaults to uncapped under explicit admission policy; authority leases stay finite and renewal cannot extend configured limits, broaden scope or reopen terminal work. Every initial GitHub operation requires current online OCC authority. Durable receipts preserve original work and operation identity across replacement; unknown submission requires reconciliation without blind replay. MVP publication permits any configured, authorized human approver, including the requester, and excludes Agent approval.

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

Reading Guide

• Service-owned work authority and detailed specification.
• Related drafts: #68, #69, #71.

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.

What this changes

This PR proposes service-owned Work records with immutable scope, shared helper cancellation, finite authority leases, and staged human-approved publication.

Example: Alice asks a repository review service to inspect an administrator-approved repository.

• Before: RFC 0027 defines workload authorization but leaves request-level scope, cancellation ownership, and durable effect identity unspecified.
• After: The proposed root Work record binds Alice’s request to its scope, execution, helpers, cancellation dependencies, and operation receipts.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The documentation is coherent and visually supported, with no actionable findings; readiness remains capped by unresolved product direction.
Proof confidence	🐚 platinum hermit (4/6) ✨ media proof bonus	Sufficient (screenshot): The inspected committed preview and diagram show the changed documentation; the specification explicitly reserves runtime authorization, cancellation, and provider qualification for implementation.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Product

Kind: Feature · Worth it: Needs a maintainer decision
User problem: Long-running repository work needs stable scope, cancellation ownership, and trustworthy outcomes across turns and credential changes.
Reason: The proposal adds a useful distinct contract, but accepting its service-ownership policy, duration default, and delivery stages requires an architecture owner decision.

Merge readiness

⛔ Blocked before merge - 2 items remain

Keep this PR open for RFC acceptance: it contributes a distinct Work authority proposal absent from main, with no actionable document defect found.

Priority: P3
Reviewed head: 947088eb41a665355b90a15f6390e3fb32cb4a8b
Owner decision: Required. See Decision needed.

Decision needed

• Question: Should RFC 0027 gain this root Work contract, uncapped execution default, and read-first sequence followed by human-approved publication?
• Recommendation: Discuss the staged contract: Evaluate the initial root/helper boundary and unresolved qualification questions through the RFC process before recording acceptance.
• Why: These are new platform policy and lifecycle contracts, and no recorded owner acceptance settles their direction.

Before merge

• Complete next step - Create or link the maintainer-discussion thread required by the repository RFC lifecycle.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Findings

None.

Agent review details

How this fits together

The proposed OCC Work boundary receives authenticated invocations and current authorization, then supplies bounded execution authority and durable operation identity to repository mediation and runtime lifecycle owners.

flowchart LR
Requester[Authenticated requester] --> OCC[OCC admission]
IAM[Current authorization] --> OCC
OCC --> Work[Root Work record]
Work --> Helpers[Execution and helpers]
Helpers --> Mediation[Trusted repository mediation]
Mediation --> GitHub[GitHub operations]
Mediation --> Receipts[Durable operation receipts]

Loading

Technical review

Best possible solution:

Resolve the staged Work contract through RFC discussion, then record acceptance and link an implementation issue if approved.

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

This PR proposes future behavior rather than reporting a reproducible runtime failure.

Is this the best way to solve the issue?

The root-only initial profile coherently separates admission, execution, credential custody, and effects, but its platform policies require RFC acceptance.

AGENTS.md: not found in the target repository.

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

Security

None.

Evidence

What I checked:

• Distinct proposal: The pinned introduction adds the RFC, supporting specification, diagram source, and images; the default-branch tree and scoped content searches contain no corresponding Work authority contract. (rfcs/0036-turn-bound-delegated-authority.md:16, 947088eb41a6)
• RFC acceptance boundary: README requires a maintainer-discussion thread, acceptance, an implementation issue, and accepted metadata before merge; this proposal remains draft with a blank issue. (README.md:78, 967d9aac7472)
• Existing architecture and feature history: RFC 0027 preserves workload authorization independent of requester credentials and requires current permission checks per operation; scoped history and the verified merged RFC 0027: OpenClaw as the Open Enterprise Agent Platform #35 identify kevinlin-openai as its architecture contributor. (rfcs/0027-openclaw-enterprise.md:288, af708f0ddb6f)
• Discussion and complementary proposals: Current comments and reviews contain no human acceptance of this PR; docs: propose credential lifecycle and GitHub App access #68, docs: propose workload identity and bounded enforcement #69, and docs: propose persistent Agent runtime lifecycle #71 remain complementary open proposals by the same author, while docs: propose guest foreground work and restart notices #74 addresses guest foreground work.
• Documentation presentation: Direct inspection of the committed preview and diagram shows readable sections, tables, and the shared helper boundary; the prepared download contained HTML rather than image data, so the verified checkout images supplied the visual evidence. (rfcs/0036/review-preview.png, 947088eb41a6)
• External proposal is not implementation: The linked docs: specify GitHub credentials, identity, Work, and runtime lifecycle openclaw-enterprise#172 is closed without merging and describes proposed contracts rather than a running integration; it establishes neither implementation nor supersession in the target repository.

Likely related people:

• kevinlin-openai: Raw commit af708f0 adds rfcs/0027-openclaw-enterprise.md:288 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)

Labels

Label changes:

No label changes.

Label justifications:

• P3: This is an architectural documentation proposal without a demonstrated current runtime failure.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action.
• proof: sufficient: Contributor real behavior proof is sufficient.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

History

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

• reviewed 2026-09-09T00:41:33.735Z sha e61605f :: needs real behavior proof before merge. :: none
• reviewed 2026-09-09T21:12:30.751Z sha c245561 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-09T21:42:52.869Z sha e61e2b4 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-11T07:47:41.913Z sha 7daf5b2 :: blocked before merge. :: none
• reviewed 2026-09-11T19:09:09.658Z sha 947088e :: blocked before merge. :: none
• reviewed 2026-09-14T21:57:56.193Z sha 947088e :: blocked before merge. :: none
• reviewed 2026-10-04T18:22:36.260Z sha 947088e :: blocked before merge. :: none
• reviewed 2026-10-10T17:00:38.135Z sha 947088e :: blocked before merge. :: none

Reviewed October 14, 2026, 4:01 AM ET / 08:01 UTC (Revision 10).