docs: rebuild Policy Conformance RFC 0003

[giodl73-repo]

What Problem This Solves

The accepted Policy Conformance RFC remained under rfcs/needs_refactoring/ and no longer described the shipped Policy command, evidence, node-command, or repair contracts.

Why This Change Was Made

Moves Policy Conformance back to numbered RFC 0003, rebuilds it in the current repository template, and adds a normative sidecar specification. The update preserves Policy as configuration conformance rather than request-time enforcement while documenting check / compare / watch, scoped strictness, named artifact evidence, Gateway node-command deny posture, fix classification, guarded automatic narrowers, and review-required previews.

User Impact

RFC readers and implementers now have a current, reviewable Policy 1.0 contract in the normal RFC layout. The stale needs_refactoring copy is removed.

Evidence

• Audited current openclaw/openclaw Policy CLI, rule metadata, fix metadata, automatic repairs, review-required repairs, and Gateway node-command checks.
• Confirmed the shipped automatic repair set, workspaceRepairs opt-in, public policy.fixRecommendation JSON shape, and current two preview implementations.
• git diff --check

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed August 22, 2026, 7:18 AM ET / 11:18 UTC.

ClawSweeper review

What this changes

The branch replaces the legacy Policy Conformance draft with numbered RFC 0003 and a normative Policy 1.0 sidecar specification.

Merge readiness

⚠️ Ready for maintainer review - 5 items remain

Current main still has the legacy Policy RFC, so this PR remains necessary; however, its accepted RFC leaves the required implementation issue blank.

Priority: P2
Reviewed head: 7770a4bfe76af57cb2b5551f5351319cf367aaf0
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The RFC is substantial, but the unresolved accepted-RFC metadata requirement prevents a merge-ready rating.
Proof confidence	🌊 off-meta tidepool	Not applicable: All changed files are RFC documentation, so real runtime behavior proof is not applicable.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: All changed files are RFC documentation, so real runtime behavior proof is not applicable.
Evidence reviewed	4 items	Central change is absent from main: Current main retains the legacy Policy Conformance document and has neither proposed RFC 0003 path, so the PR is not implemented or superseded on main. Accepted-RFC lifecycle requirement: The repository lifecycle requires an accepted RFC to contain its implementation GitHub issue URL, but this branch marks RFC 0003 accepted with an empty issue field. RFC-process provenance: The current lifecycle guidance dates to the RFC-process update by kevinlin-openai, establishing the accepted-status-to-implementation-issue contract used here.
Findings	1 actionable finding	[P2] Populate the accepted RFC’s implementation issue
Security	None	None.

How this fits together

OpenClaw RFCs preserve design contracts for the main product. This PR moves the Policy conformance design from the legacy holding area into the numbered RFC layout, where accepted RFCs must link to their implementation work.

flowchart LR
A[Policy implementation] --> B[Policy RFC 0003]
B --> C[Implementation issue link]
C --> D[Maintainer review]
D --> E[Numbered RFC archive]

Loading

Decision needed

Question	Recommendation
Which implementation issue owns the accepted Policy RFC, or should RFC 0003 return to draft until one exists?	Link the implementation issue: Confirm the owning Policy implementation issue and add its full URL to the RFC frontmatter.

Why: The repository requires an accepted RFC to name its implementation issue, but the review context does not identify one and choosing to create or defer that work is a maintainer decision.

Before merge

• Add real behavior proof - Not applicable: All changed files are RFC documentation, so real runtime behavior proof is not applicable.
• Populate the accepted RFC’s implementation issue (P2) - This frontmatter marks the RFC accepted while leaving issue empty. The repository lifecycle requires the implementation GitHub issue URL before an accepted RFC is merged; add that link, or keep the RFC in draft until the implementation work is sponsored.
• Resolve merge risk (P1) - Merging an accepted normative RFC without its implementation issue breaks the repository's required trace from design contract to delivery work.
• Complete next step (P2) - A maintainer must identify the actual implementation issue or decide whether acceptance should be deferred; automation cannot choose that product-delivery relationship.

Findings

• [P2] Populate the accepted RFC’s implementation issue — rfcs/0003-policy-conformance.md:7-8

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
RFC document movement	418 added, 219 removed across 3 files	The branch replaces one legacy RFC with a numbered RFC and a 229-line normative sidecar, making the implementation trace important.

Merge-risk options

Maintainer options:

1. Restore RFC traceability (recommended)
   Add the confirmed implementation issue URL before merging so the accepted design has a maintained delivery owner.
2. Defer acceptance
   Keep the rebuilt RFC as draft until an implementation issue and sponsor are available.

Technical review

Best possible solution:

Link the concrete Policy implementation issue in the RFC frontmatter, then keep this numbered RFC and sidecar as the reviewable Policy contract.

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

Not applicable: this PR changes RFC documents only, and the metadata mismatch is directly verifiable from the documents.

Is this the best way to solve the issue?

No: the numbered RFC layout is appropriate, but the accepted status is incomplete until it links the implementation issue or returns to draft.

Full review comments:

• [P2] Populate the accepted RFC’s implementation issue — rfcs/0003-policy-conformance.md:7-8
  This frontmatter marks the RFC accepted while leaving issue empty. The repository lifecycle requires the implementation GitHub issue URL before an accepted RFC is merged; add that link, or keep the RFC in draft until the implementation work is sponsored.
  Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.98

AGENTS.md: not found in the target repository.

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

Labels

Label justifications:

• P2: The missing implementation link is a normal-priority RFC lifecycle defect that blocks traceability but does not affect runtime availability.
• merge-risk: 🚨 other: An accepted normative RFC without its required implementation issue loses the documented design-to-delivery trace.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: All changed files are RFC documentation, so real runtime behavior proof is not applicable.

Evidence

What I checked:

• Central change is absent from main: Current main retains the legacy Policy Conformance document and has neither proposed RFC 0003 path, so the PR is not implemented or superseded on main. (rfcs/needs_refactoring/policy-conformance.md:1, af708f0ddb6f)
• Accepted-RFC lifecycle requirement: The repository lifecycle requires an accepted RFC to contain its implementation GitHub issue URL, but this branch marks RFC 0003 accepted with an empty issue field. (README.md:92, af708f0ddb6f)
• RFC-process provenance: The current lifecycle guidance dates to the RFC-process update by kevinlin-openai, establishing the accepted-status-to-implementation-issue contract used here. (README.md:88, e366ea9825a4)
• Prior blocker remains unresolved: The previous review raised the same missing implementation issue at the identical current head SHA; no new commit resolves it. (rfcs/0003-policy-conformance.md:8, 7770a4bfe76a)

Likely related people:

• kevinlin-openai: Authored both the current RFC lifecycle guidance and the refactor that shaped the legacy Policy RFC path. (role: RFC process author and legacy-document refactor contributor; confidence: high; commits: e366ea9825a4, 5f9f47ac8529; files: README.md, rfcs/0000-template.md, rfcs/needs_refactoring/policy-conformance.md)

Rank-up moves

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

• Add the confirmed implementation issue URL, or restore draft status until that work is sponsored.

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 (57 earlier review cycles; latest 8 shown)

• reviewed 2026-08-09T23:10:07.131Z sha 7770a4b :: needs real behavior proof before merge. :: [P2] Populate the accepted RFC's implementation issue
• reviewed 2026-08-11T06:09:10.319Z sha 7770a4b :: needs real behavior proof before merge. :: [P2] Populate the accepted RFC’s implementation issue
• reviewed 2026-08-11T06:13:35.399Z sha 7770a4b :: needs real behavior proof before merge. :: [P2] Link the accepted RFC to its implementation issue
• reviewed 2026-08-11T21:15:33.687Z sha 7770a4b :: needs real behavior proof before merge. :: [P2] Link the accepted RFC to its implementation issue
• reviewed 2026-08-12T01:56:08.013Z sha 7770a4b :: needs real behavior proof before merge. :: [P2] Add the accepted RFC's implementation issue
• reviewed 2026-08-14T16:08:14.566Z sha 7770a4b :: needs real behavior proof before merge. :: [P2] Link the accepted RFC to its implementation issue
• reviewed 2026-08-14T19:49:34.885Z sha 7770a4b :: needs real behavior proof before merge. :: [P2] Populate the accepted RFC's implementation issue
• reviewed 2026-08-22T09:55:52.057Z sha 7770a4b :: needs real behavior proof before merge. :: [P2] Populate the accepted RFC's implementation issue