enforce-server-side-gate-parity

Enforces server-side authorization gates on API routes that bypass the sequencer when persisting physical facts.

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/shuddl/shuddl-os --skill enforce-server-side-gate-parity-shuddl
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: enforce-server-side-gate-parity
Source: https://github.com/shuddl/shuddl-os/tree/main/.claude/skills/enforce-server-side-gate-parity
Command: npx skills add https://github.com/shuddl/shuddl-os --skill enforce-server-side-gate-parity-shuddl

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? API routes that bypass the sequencer Durable Object can silently drop the authorization gates the sequencer would have enforced, letting drivers post GPS positions or physical facts for shipments they are not assigned to, under devices they do not own, or without consent. ## Core Features & Use Cases - Gate Parity Enforcement: Requires every API-reachable write of a gated physical fact (raw GPS, stop.arrived/departed, POD, custody, appointments) to re-invoke the same predicates the sequencer DO applies, per REQ-030. - Shared Predicate Module: Factors assignmentOf, deviceOwnedBy, and streamPrior into one module imported by both the route and the DO so authorization cannot drift between paths. - Static Lint Design: Provides a CI lint specification that fails the build when a write path persists a gated fact without calling the required predicates, including detection of unregistered stealth bypass routes. - Use Case: When adding a positions ingestion route that skips the sequencer for throughput, apply this Skill to add driver-assignment, device-ownership, and consent-before-GPS checks with server-derived operating state before the INSERT. ## Quick Start Review the new positions write route and add the assignmentOf, deviceOwnedBy, and assertConsentBeforeGps checks before its INSERT so it matches the sequencer gates.

Frequently Asked Questions about enforce-server-side-gate-parity

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce authorization on an API route that bypasses the sequencer?▼

Re-invoke the same predicates the sequencer Durable Object would apply before the write: assignmentOf for driver-shipment binding, deviceOwnedBy for device registration, and assertConsentBeforeGps for GPS facts. Factor these into a shared module both paths import so the checks cannot drift.

Why is client-supplied shipment_id or device_id untrusted in a write handler?▼

Schema validation like PositionInput checks shape, not authority. A client can supply any shipment_id or device_id, so the route must verify driver assignment against the status cache and device registration in users.device_keys before persisting anything.

Does consent gating apply only to stop.arrived events?▼

No. The raw positions partition is also a first GPS stamp and must be gated with assertConsentBeforeGps per REQ-166. The operating state must be derived server-side from the stamp's own coordinates, never taken from a client field.

Can a UI-side consent or assignment check replace the server-side gate?▼

No. A UI-only gate is not a gate because the API path is reachable directly. REQ-030 requires the server to enforce the predicate on every API-reachable write of a gated physical fact.

What happens when a new bypass route is added without registering it?▼

The gate-parity lint fails the build. Its stealth-bypass rule greps for writes to physical-fact tables outside SHIPMENT_SEQ.append, and any write site not listed in the bypass registry is an un-audited path that fails CI.

When should this gate-parity skill not be applied?▼

Do not apply it to pure reads, which lens scoping owns, or to server-internal seams like Biller and Rater that call SHIPMENT_SEQ.append directly and re-traverse the Durable Object gates.