Ruo Supabase Guardrails

RUO Supabase Guardrails

Use this skill whenever an agent is asked to read, change, configure, migrate, sync, inspect, or automate Supabase for RUO Peptides / PeptraLabs.

This skill separates read-only analysis from mutation ownership. Hermes is the sole agent allowed to execute RUO Supabase mutations. Codex, Claude Code, Genie, OpenClaw helpers, and other non-Hermes agents may inspect read-only state and prepare a mutation instruction set, but they must never write directly.

Quick Rule

RUO Supabase is read-only for every non-Hermes agent.

There is no approval exception for direct Codex/API writes. Pafi approval authorizes Hermes to evaluate and execute the exact instruction set; it never authorizes the preparing agent to execute the mutation.

For every proposed mutation, the preparing agent must:

1. keep all Supabase access read-only;
2. assemble the Hermes Supabase Mutation Instruction Set defined by ruo-supabase-mutation-audit;
3. validate the instruction set locally;
4. deliver it to Hermes or return it as a ready-to-send handoff if Hermes is unavailable; and
5. wait for Hermes execution evidence before describing the database as changed.

Non-Hermes Hard Boundary

Non-Hermes agents must not perform or invoke:

• POST, PATCH, PUT, or DELETE against Supabase REST or Storage endpoints;
• mutating RPC or Edge Function calls;
• SQL INSERT, UPDATE, UPSERT, DELETE, DDL, grants, or policy changes;
• Supabase CLI migration apply, db push, deployment, secret, RLS, storage, or configuration mutations;
• a local helper whose execution path can mutate RUO Supabase; or
• any compensating or rollback mutation after a failed read or Hermes execution.

If a direct-write helper already exists, it may be inspected as historical implementation evidence, but it must not be run in mutation mode. Convert the requested change into a Hermes instruction set instead.

Explicit Pafi approval for a business change does not override this executor boundary. Changing the executor boundary itself requires a separate, explicit policy change and a new skill/procedure version.

Credential Boundary

Non-Hermes agents must use only a credential or mediated access path that is technically restricted to read-only operations.

• Never load or use the RUO Supabase service-role credential in a non-Hermes runtime.
• Never print, quote, commit, log, copy, or embed Supabase credentials in a handoff.
• Reference secrets by owner-managed handle only; Hermes resolves them inside its own runtime.
• If no read-only credential/path is available, ask Hermes to run the read and return a redacted snapshot. Do not fall back to the service-role key.
• If a user pastes a key, do not replay it in commands or files.

This credential rule is required for capability separation: a policy-only block is not a technical write barrier while a write-capable credential remains available to the preparing agent.

Trigger Conditions

Use this skill for:

• RUO/PeptraLabs Supabase reads, schema inspection, exports, imports, syncs, payments, transactions, balances, stock, SKU states, approvals, evidence links, or exception statuses;
• Airtable-to-Supabase migration planning or legacy Airtable reconciliation;
• Codex, Claude Code, Genie, Hermes, OpenClaw, dashboard, or automation access to RUO Supabase; and
• any request involving Supabase credentials, runtime access, schema/config, RLS, storage, RPC, Edge Functions, migrations, or mutation helpers.

Do not use this skill for generic Supabase tutorials or unrelated applications.

Source Of Truth

• Airtable is frozen and read-only as legacy evidence.
• Supabase/dashboard is the active operational source for payments, transactions, balances, stock movements, SKU states, approvals, evidence, exceptions, and reports.
• Hermes owns all Supabase mutations and mutation credentials.
• Non-Hermes agents own read-only analysis, preflight evidence, instruction-set preparation, and independent post-execution verification when a read-only path exists.
• If project cards, dashboards, Cortex, LLM-Wiki, or chat summaries disagree with Supabase, report the conflict. Do not invent a merged state.

Read Workflow

For read-only work:

1. Confirm the request concerns RUO/PeptraLabs Supabase.
2. Confirm the action is genuinely read-only: select, schema inspect, export, checksum, count, diff, or validation.
3. Use only a technically read-only credential/path. If unavailable, route the read to Hermes.
4. Run the smallest query needed.
5. Redact customer, payment, credential, and other sensitive fields unless the request requires them.
6. Report source table/view, query scope, timestamp, row count, and limits.
7. State Writes performed: none.

Hermes Mutation Instruction Gate

Before any proposed insert, update, upsert, delete, RPC mutation, storage change, migration, backfill, trigger, RLS policy, schema/config change, runtime access change, or dashboard-to-Supabase sync, create an instruction set containing at least:

contract_version: hermes-supabase-instruction.v1
instruction_set_id: stable unique reference
execution_owner: Hermes-main
executor: hermes
executor_profile: default
codex_direct_write_forbidden: true
approval_explicit: true only when Pafi approved this exact business change
approval_source: exact chat/thread/channel/message or approval artifact
approval_timestamp: ISO timestamp
operation: requested mutation type
surface: data_row/financial_stock/schema_config/rls_policy/storage/rpc_function/runtime_secret_config/dashboard_sync
objects: exact tables, rows, buckets, functions, policies, or config objects
scope: exact IDs or precise filter and expected count
payload_summary: intended change without secrets
mutation_steps: ordered exact operations for Hermes
preflight_diff: observed state versus intended state
required_markers: Pafi-authorized plus Hermes owner attribution
idempotency: duplicate-prevention rule
rollback: exact undo or compensating plan
domain_invariants: money/stock/account/config/compliance checks
post_write_verification: read-back checks and expected values
artifact_sync: required follow-up surfaces or explicit no-sync reason
return_contract: evidence Hermes must return

Run ruo-supabase-mutation-audit against this packet. A valid result is HANDOFF_READY, never permission for the preparing agent to execute.

If approval is missing, the packet may be prepared as DRAFT_AWAITING_PAFI_APPROVAL, but it must not be presented to Hermes as executable.

Hermes Execution And Return Contract

Hermes-main using the explicit default profile must independently:

1. verify the approval, current state, exact scope, and expected count;
2. select its owner-managed execution path without exposing credentials;
3. apply required audit actor/markers and idempotency controls;
4. execute only the approved scope;
5. read back affected records/objects;
6. run domain invariants and rollback if required; and
7. return structured evidence with status, timestamps, affected IDs/counts, redacted before/after values, markers/actor, invariant results, rollback status, artifact-sync status, and exceptions.

Codex or another preparing agent may perform an independent read-only verification after Hermes returns. It must not repair a mismatch directly; it prepares a follow-up Hermes instruction set.

RUO Stock Model Facts For Hermes Instructions

• stock_movements is the movement ledger.
• location_stock.qty is the per-location quantity for Ibiza and other non-main locations.
• skus.stock_qty is the Bucharest/main basis used by v_stock_by_location, not a global stock total.
• An Ibiza-only movement must target stock_movements and location_stock; it must not decrement skus.stock_qty.
• A Bucharest/main movement must use the Bucharest/main basis and must not be described as a global correction.

Every stock instruction set must require Hermes to verify the movement row, the affected location aggregate, v_stock_by_location, and the absence of accidental customer/payment records.

Airtable Freeze Rule

Do not write new operational state to Airtable. Treat Airtable as historical evidence only. Any proposed Airtable-to-Supabase sync becomes a Hermes instruction set after source reconciliation and exact approval.

Financial And Stock Data

When a proposed mutation affects money, payments, balances, stock, SKU disposition, customer credit, owner investment, restocks, costs, or published audit figures, also apply ruo-financial-audit-controller before marking the instruction set ready.

The control matrix and invariants are inputs to Hermes. They do not authorize direct execution by the preparing agent.

Output Contract

For read-only work:

Mode: READ_ONLY
Source: table/view and query scope
Rows reviewed: ...
Findings: ...
Writes performed: none

For an incomplete mutation handoff:

Mode: HANDOFF_BLOCKED
Missing/failed fields: ...
Hermes delivery: not executable
Supabase writes performed: none

For a valid mutation handoff:

Mode: HANDOFF_READY
Executor: Hermes
Instruction set: ...
Approval/scope/invariants/rollback: ...
Supabase writes performed by preparing agent: none

For returned Hermes evidence:

Mode: HERMES_EXECUTION_REPORTED
Hermes result: ...
Independent read-only verification: verified/not_run/exception
Residual exceptions: ...
Supabase writes performed by preparing agent: none

Test Cases

1. A payment lookup uses a technically read-only path and reports Writes performed: none.
2. A mutation request without exact approval returns HANDOFF_BLOCKED or a non-executable draft.
3. Pafi approves one exact row update. The preparing agent emits HANDOFF_READY for Hermes and performs no write.
4. Pafi asks Codex to call Supabase REST directly. The skill refuses the executor path and converts the request into a Hermes instruction set.
5. An Ibiza BAC Water adjustment becomes a Hermes stock instruction with location-specific invariants; Codex does not insert or update rows.
6. Only a service-role credential is available to Codex. Codex does not load it and routes the read or mutation to Hermes.