RFC 0030: Claws Eve portability profile

[giodl73-repo]

Summary

Adds a draft RFC for a non-normative Claws <> Eve portability profile.

The proposal keeps RFC 0016 independent of Eve while defining a reviewable mapping between Claw packages and Eve agent/template projects. It calls out authority, managed-instruction, resource, subagent, update-drift, and proof-parity requirements that should survive any bridge.

Proposed first demos

1. Port Eve's Marketing Team template into an Awesome Claws package.
2. Port one manager-Claw pattern, preferably Delegation Coordinator or Work Chief of Staff, into an Eve team-style template.

Context

This follows the discussion on RFC #48 and the current Claws <> Eve collaboration thread. It is intentionally a draft/follow-up profile, not a merge blocker for RFC 0016.

Refs:

• RFC RFC 0016: consolidate the Claws contract #48: RFC 0016: consolidate the Claws contract #48
• Eve dynamic instructions: https://eve.dev/docs/instructions#dynamic-instructions
• Eve templates: https://eve.dev/templates
• Eve Marketing Team template: https://eve.dev/templates/marketing-team-eve-template
• Awesome Claws manager set: Add lifecycle capstone Claws giodl73-repo/awesome-claws#25
• Household Steward: Add Household Steward giodl73-repo/awesome-claws#48
• Work Chief of Staff: Add Work Chief of Staff giodl73-repo/awesome-claws#50

Proof

Docs-only draft. Read-through performed locally.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

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

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed August 22, 2026, 12:09 PM ET / 16:09 UTC.

ClawSweeper review

What this changes

The PR adds a draft non-normative portability profile mapping Claw packages to Eve agent and template projects.

Merge readiness

⚠️ Ready for maintainer review - 5 items remain

This distinct, docs-only draft is not implemented on current main and needs maintainer product direction on its scope, permanent home, and proof bar before its cross-runtime mapping is accepted.

Priority: P3
Reviewed head: 322ed2a74756d76caca07e0398ab753089c278ba
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The draft follows the repository RFC layout, but its acceptance depends on unresolved maintainer direction and proof of the cross-runtime authority mapping.
Proof confidence	🌊 off-meta tidepool	Not applicable: This is a documentation-only RFC draft; runtime behavior did not change, so real behavior proof is not applicable.
Patch quality	🦐 gold shrimp (3/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This is a documentation-only RFC draft; runtime behavior did not change, so real behavior proof is not applicable.
Evidence reviewed	4 items	RFC structure matches repository guidance: The PR uses the required RFC frontmatter, proposal sections, and an RFC-numbered sidecar, which the repository README permits for supporting material. Current main has no Eve portability profile: The branch adds two RFC 0030 Markdown documents relative to current main; no current-main implementation of this proposal exists. Underlying contract is separate: Current main’s RFC 0016 supplies the portable Claw contract, while this proposal expressly layers on it and says it is not a merge blocker; the related RFC remains open.
Findings	None	None.
Security	None	None.

How this fits together

RFC 0016 defines portable Claw packages and their owned resources. This draft proposes a translation profile between those packages and Eve templates while preserving authority and approval boundaries.

flowchart LR
A[Claw package contract] --> B[Portability profile]
C[Eve template project] --> B
B --> D[Field and resource mapping]
D --> E[Authority and approval checks]
E --> F[Reviewed demo artifacts]

Loading

Decision needed

Question	Recommendation
Should OpenClaw adopt an Eve-specific portability profile in this RFC repository before the proposed bidirectional demos prove the mapping and authority boundaries?	Sponsor a bounded draft: Keep this RFC as a non-normative exploration and require the two pinned demos plus approval-boundary proof before an acceptance decision.

Why: The PR introduces a new cross-runtime contract, and its unresolved questions include both the permanent home and minimum conformance proof; source review cannot safely choose that product direction.

Before merge

• Add real behavior proof - Not applicable: This is a documentation-only RFC draft; runtime behavior did not change, so real behavior proof is not applicable.
• Resolve merge risk (P1) - The profile uses normative mapping and authority language before a bidirectional demo establishes that Eve preserves the specified approval and provenance semantics.
• Resolve merge risk (P1) - Merging a repository-level interoperability profile could create an unsupported compatibility expectation for Eve templates unless maintainers explicitly sponsor its scope and proof bar.
• Complete next step (P2) - Maintainer product sponsorship is required before implementation or automated repair can proceed.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
RFC surface	2 Markdown files, +338 lines	The patch adds RFC material only, with no executable code, dependencies, or runtime configuration.

Merge-risk options

Maintainer options:

1. Require a proof-backed draft boundary (recommended)
   Retain the draft only with an explicit maintainer decision that no compatibility guarantee exists until the two mapped demos document unresolved fields and approval behavior.
2. Defer to a joint exploration
   Pause this repository-level RFC until the portability work has a jointly owned home and implementation evidence.

Technical review

Best possible solution:

Keep this as a scoped draft only if maintainers sponsor an RFC-repository portability track, then require one pinned bidirectional demo with explicit approval-boundary and unsupported-field evidence before acceptance.

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

Not applicable: this is a documentation-only RFC proposal, not a report of broken current behavior.

Is this the best way to solve the issue?

Unclear: the draft is a coherent exploration, but maintainers must first choose its home and proof bar before the profile’s normative mapping can be accepted.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning high; reviewed against af708f0ddb6f.

Labels

Label justifications:

• P3: This is a low-urgency draft product-direction proposal with no current runtime regression.
• merge-risk: 🚨 compatibility: Its normative mapping language could be read as a compatibility commitment across Claw packages and Eve templates.
• merge-risk: 🚨 security-boundary: The proposed contract requires preservation of approval and external-action authority across a separate runtime without a demonstrated enforcement path.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This is a documentation-only RFC draft; runtime behavior did not change, so real behavior proof is not applicable.

Evidence

What I checked:

• RFC structure matches repository guidance: The PR uses the required RFC frontmatter, proposal sections, and an RFC-numbered sidecar, which the repository README permits for supporting material. (README.md:43, 322ed2a74756)
• Current main has no Eve portability profile: The branch adds two RFC 0030 Markdown documents relative to current main; no current-main implementation of this proposal exists. (rfcs/0030-claws-eve-portability.md:16, 322ed2a74756)
• Underlying contract is separate: Current main’s RFC 0016 supplies the portable Claw contract, while this proposal expressly layers on it and says it is not a merge blocker; the related RFC remains open. (rfcs/0016-claws.md:16, 13819ef73d3a)
• Authority mapping remains unproven: The sidecar defines authority classes and approval preservation, but remains non-normative until both directions have reviewed demos; the RFC leaves the proof mechanism unresolved. (rfcs/0030/claws-eve-portability-profile-v0.md:87, 322ed2a74756)

Likely related people:

• Gio Della-Libera: Authored the current-main RFC 0016 Claws contract as well as this portability proposal. (role: introduced the current Claws contract; confidence: high; commits: 13819ef73d3a, 322ed2a74756; files: rfcs/0016-claws.md, rfcs/0016/claw-package-v1-spec.md, rfcs/0030-claws-eve-portability.md)
• kevinlin-openai: Authored the repository RFC-process update and the current main commit, making them a relevant routing candidate for repository-level RFC scope. (role: RFC-process contributor; confidence: medium; commits: e366ea9825a4, af708f0ddb6f; files: README.md)

Rank-up moves

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

• Obtain a maintainer decision on whether the profile belongs in this RFC repository.
• Add pinned bidirectional demo evidence showing unsupported-field reporting and an approval-gated external action.

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

• reviewed 2026-08-21T22:10:30.621Z sha 46a2095 :: needs real behavior proof before merge. :: none
• reviewed 2026-08-21T22:20:18.188Z sha 322ed2a :: needs real behavior proof before merge. :: none