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 11, 2026, 3:09 PM ET / 19:09 UTC (Revision 6).

ClawSweeper review

What this changes

Adds a draft RFC, supporting specification, and diagrams proposing service-owned repository work with shared helper limits, cancellation, finite authority leases, and staged publication support.

Merge readiness

⛔ Blocked before merge - 3 items remain

Keep open for RFC acceptance. The proposal adds distinct design work beyond the accepted Enterprise RFC, and the latest revision resolves the previously open initial-helper scope. No blocking patch defect was found.

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 proposal with adequate document proof and no blocking patch findings; RFC acceptance remains outstanding.
Proof confidence	🐚 platinum hermit (4/6) ✨ media proof bonus	Sufficient (screenshot): The pinned rendered preview demonstrates the changed RFC's text, stage table, and helper diagram; runtime authority qualification is expressly outside this documentation patch.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): The pinned rendered preview demonstrates the changed RFC's text, stage table, and helper diagram; runtime authority qualification is expressly outside this documentation patch.
Evidence reviewed	8 items	Repository lifecycle requires acceptance: README requires a maintainer-discussion thread, acceptance, an implementation issue, and accepted frontmatter before merging a new RFC. The proposed document correctly remains draft with an empty issue field. Complete introduced scope: The pinned introduction adds two Markdown documents, one Graphviz source, and two PNGs: 441 text lines and no runtime, dependency, workflow, or storage implementation changes. The full local documents were inspected beyond the supplied truncated patch; git diff --check reported no whitespace errors. Previous scope concern addressed: The exact-head commit patch replaces the open initial-child subset with root Work and subordinate helpers, explicitly deferring durable children and cross-attempt continuation. The local prior-revision diff encountered an unavailable blob; the GitHub commit API supplied the revision patch instead.
Findings	None	None.
Security	None	None.

How this fits together

The proposed Work record sits between an authenticated request and Enterprise Agent execution. The OpenClaw Controller would bind repository operations to the original request, current permissions, cancellation, and recorded 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 receipt]

Loading

Decision needed

Question	Recommendation
Should the Enterprise design adopt root Work with subordinate helpers first, followed by human-approved publication and later durable Work lifecycle features?	Accept the staged contract: Approve the root-first design and track supplier integration and qualification in the required implementation issue.

Why: The revision now selects a concrete sequence, but accepting that architecture belongs to the repository's RFC decision process.

Before merge

• Resolve merge risk (P1) - The qualifying runtime, numerical withdrawal profiles, and requester-dependency policy remain unspecified; document acceptance would not establish deployment readiness.
• Complete next step (P2) - Complete the RFC decision in maintainer-discussion; if accepted, create the implementation issue, link it in frontmatter, and change status to accepted before merge.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

None.

Merge-risk options

Maintainer options:

1. Decide the mitigation before merge
   Adopt a clearly staged root Work contract that preserves existing authority boundaries and makes implementation qualification explicit before repository operations ship.
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 clearly staged root Work contract that preserves existing authority boundaries and makes implementation qualification explicit before repository operations ship.

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

Not applicable: this PR proposes an architecture rather than reporting an executable defect; its document rendering was inspected.

Is this the best way to solve the issue?

Yes, as a proposal: the root-first scope avoids requiring general durable orchestration for repository reads while preserving qualification requirements. Product acceptance remains a separate decision.

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 change to deployed behavior or evidence of an urgent regression.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit 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 pinned rendered preview demonstrates the changed RFC's text, stage table, and helper diagram; runtime authority qualification is expressly outside this documentation patch.
• proof: sufficient: Contributor real behavior proof is sufficient. The pinned rendered preview demonstrates the changed RFC's text, stage table, and helper diagram; runtime authority qualification is expressly outside this documentation patch.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The pinned rendered preview demonstrates the changed RFC's text, stage table, and helper diagram; runtime authority qualification is expressly outside this documentation patch.

Evidence

What I checked:

• Repository lifecycle requires acceptance: README requires a maintainer-discussion thread, acceptance, an implementation issue, and accepted frontmatter before merging a new RFC. The proposed document correctly remains draft with an empty issue field. (README.md:78, 967d9aac7472)
• Complete introduced scope: The pinned introduction adds two Markdown documents, one Graphviz source, and two PNGs: 441 text lines and no runtime, dependency, workflow, or storage implementation changes. The full local documents were inspected beyond the supplied truncated patch; git diff --check reported no whitespace errors. (rfcs/0036-turn-bound-delegated-authority.md:15, 947088eb41a6)
• Previous scope concern addressed: The exact-head commit patch replaces the open initial-child subset with root Work and subordinate helpers, explicitly deferring durable children and cross-attempt continuation. The local prior-revision diff encountered an unavailable blob; the GitHub commit API supplied the revision patch instead. (rfcs/0036/work-authority-spec.md:15, 947088eb41a6)
• Existing authority foundation and routing history: The accepted Enterprise RFC requires current per-operation workload authorization and prevents inheritance of human credentials. File history and blame identify kevinlin-openai's merged Enterprise proposal as the relevant foundation; it does not supply this proposed root Work contract. (rfcs/0027-openclaw-enterprise.md:298, af708f0ddb6f)
• Merged foundation is not a replacement: GitHub confirms RFC 0027: OpenClaw as the Open Enterprise Agent Platform #35 merged the Enterprise foundation. The provided companion proposals remain open and divide credential mediation, enforcement, and runtime lifecycle responsibilities; none establishes a merged replacement for this proposal. (rfcs/0027-openclaw-enterprise.md:9, af708f0ddb6f)
• Current-main and release check: The current-main tree lacks the proposed files, and searches for logical Work, root Work, and Work authority found no corresponding contract. The GitHub releases endpoint returned zero releases; there is no established released or merged implementation supporting closure. (967d9aac7472)

Likely related people:

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