RuleFence developer guide

Extend the control model.
Never the privilege boundary.

Build on the WordPress Ability lifecycle with explicit identity, native authorization, narrower policy, readable evidence, and honest recovery limits.

Explore the architecture Open documentation
Abilities-first Native authorization first Versioned contracts
Managed request contract Boundary active
REQUEST ENVELOPE
managed_request {
  identity: agent,
  ability: registered,
  input: fingerprinted,
  environment: explicit
}
No extension may create authority.

EXECUTION LIFECYCLE

01IdentifyManaged actor
02AuthorizeWordPress callback
03DecideNarrower policy
04ExecuteRegistered Ability
05VerifyOutcome evidence
Native denial remains denialIdentity → Authority → Policy → Execution → Evidence

Architecture map

One lifecycle. Five responsibilities.

Keep each integration responsibility narrow. The complete boundary appears only when every layer remains visible.

01

Identify

Resolve the managed actor and environment.

02

Authorize

Preserve the registered WordPress permission result.

03

Decide

Apply agent policy that can only narrow access.

04

Execute

Run the registered Ability with bounded input.

05

Verify

Record the decision and observable outcome.

Security invariants

Extensions may add evidence. They may not add privilege.

Every provider and adapter stays inside the same control path. Treat these invariants as release-blocking contracts, not optional guidance.

  • A native denial can never become permission
  • Unknown Abilities remain blocked
  • Approval is bound to the exact request
  • Sensitive input stays out of evidence
Read the security model
Invariant checks Required
Native authorizationPreserved
Agent stateActive
Ability decisionExplicit
Unknown authorityBlocked
Audit writeRequired
Fail closed when required state or evidence is unavailable.

Extension contracts

Add domain knowledge at explicit seams.

An integration improves classification, previews, verification, recovery, or presentation without bypassing the governed request path.

Classification metadata

Describe action, data, scope, risk, and reversibility conservatively.

Governed contract

Preview provider

Summarize the expected change without executing the Ability.

Governed contract

Outcome verification

Compare supported fields after execution and report what is known.

Governed contract

Snapshot and restore

Capture and restore only fields the provider can support honestly.

Governed contract

Policy facts

Expose bounded facts that policy can use to become stricter.

Governed contract

Activity rendering

Turn structured evidence into operator-readable operational language.

Governed contract
Provider anatomy Conceptual
// Describe; never grant.
provider {
  classify( ability ),
  preview( request ),
  verify( before, after ),
  snapshot( supported_fields ),
  restore( snapshot )
}
Bounded output Redacted evidence No execution shortcut

Provider design

Return evidence, not authority.

A provider should be deterministic where possible, conservative when uncertain, and explicit about unsupported fields or side effects.

  • Validate against the live Ability registry
  • Keep previews read-only
  • Report Partial or Unverified honestly
  • Refuse unsupported recovery claims

Management surface

Automate administration without creating a shadow control plane.

Management clients should use authenticated, versioned interfaces and preserve the same validation applied in wp-admin.

Versioned schemas

Treat request and response contracts as stable interfaces. Reject unknown or invalid shapes.

Least-privilege access

Use a dedicated WordPress user and expose only the management operations it needs.

Atomic changes

Validate live state before writing permission, policy, approval, or recovery changes.

Operational evidence

Record administration events without copying credentials or raw managed input.

Boundary rule A management API may configure governance. It must not bypass native WordPress authority or the managed execution lifecycle.

Testing an integration

Test the stopped paths as carefully as the successful path.

A useful test suite proves that an integration stays safe when identity, authority, policy, approval, evidence, or recovery is missing.

  • Unit-test classification and redaction
  • Exercise native authorization failure
  • Verify approval binding and replay refusal
  • Confirm partial recovery stays partial
Integration test matrix 8 / 8
CASEKnown read AbilityAllow
CASEUnregistered AbilityBlock
CASENative denialBlock
CASEChanged approved inputBlock
CASEUnsupported restoreUnavailable
CASESensitive diagnostic fieldRedacted

Release checklist

Ship only the behaviour you can prove.

Compatibility is a tested claim. Keep versions, environments, limits, and evidence attached to it.

Contract

Schemas and provider behaviour are versioned.

Boundary

Native authority and default deny are preserved.

Tests

Success, failure, replay, and redaction paths pass.

Evidence

Diagnostics state what was verified and what was not.

Continue building

Use the right reference for the next decision.

Start with the architecture and invariants, then move to the contract closest to the evidence your integration can provide.

DocumentationOpen the complete task and reference map.Integration modelUnderstand compatibility and integration depth.Developer supportBring versions, steps, and redacted diagnostics.

Developer questions

Keep the contract honest.

When capability is uncertain, return less—not a broader promise.

Can an integration grant a WordPress Ability?+

No. It can describe or enrich a registered Ability, but it cannot bypass native WordPress authorization or create authority.

Does every provider need snapshots?+

No. Add recovery only when the provider can capture and restore supported state honestly.

Can diagnostics include raw request input?+

No. Preserve bounded, redacted evidence and keep credentials, tokens, cookies, customer records, and private keys out.

What should compatibility claims include?+

Name the tested plugin and version, WordPress environment, supported Ability names, behaviour verified, and known limits.

Build inside the boundary

Extend the evidence.
Preserve the authority ceiling.

Start with one Ability, one provider contract, and a complete stopped-path test matrix.

Open documentation Request integration help