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. Reviewed September 14, 2026, 5:57 PM ET / 21:57 UTC (Revision 7).

ClawSweeper review

What this changes

Adds a draft RFC, supporting specification, and diagrams defining service-owned repository work, shared helper limits, cancellation, and staged publication support.

Merge readiness

⛔ Blocked before merge - 2 items remain

The proposal remains distinct from the accepted enterprise RFC on main. No actionable document defect was found; merging requires the repository’s RFC acceptance process.

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

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A coherent, illustrated RFC with sufficient document proof and no actionable patch findings; acceptance remains a separate product decision.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): The checked-out rendering visibly demonstrates the changed RFC text, staged scope, and helper diagram. Documentation is the changed surface; runtime authorization and deployment proof are explicitly deferred to implementation.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): The checked-out rendering visibly demonstrates the changed RFC text, staged scope, and helper diagram. Documentation is the changed surface; runtime authorization and deployment proof are explicitly deferred to implementation.
Evidence reviewed	7 items	Repository policy and acceptance gate: README requires a maintainer-discussion thread, RFC acceptance, an implementation issue, and accepted metadata before merge. The proposal correctly remains draft with a blank issue pending acceptance. No AGENTS.md or maintainer-note files were found. Introduced scope: The pinned base-to-head comparison adds two Markdown documents, diagram source, and two PNGs: 441 text lines and no deletions. It changes no runtime, dependency, workflow, or existing stored format. Whitespace checks passed and the checkout remained clean. Main does not contain this Work proposal: The current-main tree and enterprise RFC were inspected. RFC 0027 establishes platform authorization but does not contain the proposed logical Work admission, horizon, and receipt contract. Searches for logical work, work horizon, service-owned, and original-work returned no matches on main. The repository release API returned no releases.
Findings	None	None.
Security	None	None.

How this fits together

The proposal places Work admission in the OpenClaw Controller, between authenticated requests and agent repository operations. Work records would preserve scope, cancellation dependencies, execution identity, and operation outcomes.

flowchart LR
A[Authenticated request] --> B[Controller authorization]
B --> C[Durable root Work]
C --> D[Agent and subordinate helpers]
D --> E[Current authority check]
E --> F[Mediated repository operation]
F --> G[Durable outcome]

Loading

Decision needed

Question	Recommendation
Should the root-Work scope and staged publication model be accepted as an extension to RFC 0027?	Accept the staged design: Accept the root-Work direction while carrying the documented runtime and policy qualification questions into implementation tracking.

Why: The repository requires explicit RFC acceptance, and technical consistency alone cannot establish sponsorship of the proposed enterprise contract.

Before merge

• Complete next step (P2) - Complete or confirm the maintainer-discussion thread and obtain RFC acceptance; once accepted, link the implementation issue and change the RFC metadata to accepted 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
Documentation scope	384 Markdown lines, 57 diagram-source lines, 2 PNGs; production +0, tests +0	The branch expands design documentation without changing executable behavior.

Technical review

Best possible solution:

Retain a focused root-Work contract for repository reads and approved publication, with durable children and deployment qualification explicitly staged separately.

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

Not applicable: this PR proposes an enterprise contract rather than reporting a reproducible runtime defect.

Is this the best way to solve the issue?

Yes, as a design proposal: the compact RFC and supporting specification distinguish the initial root scope from later lifecycle capabilities without claiming implementation readiness.

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 immediate runtime change or reported production incident.
• 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 checked-out rendering visibly demonstrates the changed RFC text, staged scope, and helper diagram. Documentation is the changed surface; runtime authorization and deployment proof are explicitly deferred to implementation.
• proof: sufficient: Contributor real behavior proof is sufficient. The checked-out rendering visibly demonstrates the changed RFC text, staged scope, and helper diagram. Documentation is the changed surface; runtime authorization and deployment proof are explicitly deferred to implementation.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The checked-out rendering visibly demonstrates the changed RFC text, staged scope, and helper diagram. Documentation is the changed surface; runtime authorization and deployment proof are explicitly deferred to implementation.

Evidence

What I checked:

• Repository policy and acceptance gate: README requires a maintainer-discussion thread, RFC acceptance, an implementation issue, and accepted metadata before merge. The proposal correctly remains draft with a blank issue pending acceptance. No AGENTS.md or maintainer-note files were found. (README.md:78, 947088eb41a6)
• Introduced scope: The pinned base-to-head comparison adds two Markdown documents, diagram source, and two PNGs: 441 text lines and no deletions. It changes no runtime, dependency, workflow, or existing stored format. Whitespace checks passed and the checkout remained clean. (rfcs/0036-turn-bound-delegated-authority.md:1, 947088eb41a6)
• Main does not contain this Work proposal: The current-main tree and enterprise RFC were inspected. RFC 0027 establishes platform authorization but does not contain the proposed logical Work admission, horizon, and receipt contract. Searches for logical work, work horizon, service-owned, and original-work returned no matches on main. The repository release API returned no releases. (rfcs/0027-openclaw-enterprise.md:234, 967d9aac7472)
• Existing enterprise design provenance: Current-main file history identifies the enterprise RFC commit. GitHub independently confirms RFC 0027: OpenClaw as the Open Enterprise Agent Platform #35 merged with that SHA and identifies kevinlin-openai as its author. The raw recorded parent was inspected; its tree lacks this RFC path. (rfcs/0027-openclaw-enterprise.md:245, af708f0ddb6f)
• Rendered documentation proof: The prepared download was HTML despite its PNG filename, so the exact checked-out PNG was inspected directly. It visibly renders the current proposal, delivery stages, helper diagram, and unresolved questions without apparent clipping. This establishes documentation presentation, not runtime enforcement. (rfcs/0036/review-preview.png, 947088eb41a6)
• Security and qualification boundaries: The full specification separates invocation from service authorization, binds references to authenticated presenters, preserves original operation identity, and denies reuse of expired or withdrawn authority. Its qualification section expressly describes future implementation evidence rather than claiming deployed guarantees. (rfcs/0036/work-authority-spec.md:268, 947088eb41a6)

Likely related people:

• kevinlin-openai: Raw commit af708f0 adds rfcs/0027-openclaw-enterprise.md:245 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 (6 earlier review cycles)

• reviewed 2026-09-08T22:14:56.037Z sha 36b93ea :: needs real behavior proof before merge. :: none
• 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