Activate for any ticket that touches a Supabase RPC, edge function, or TypeScript client function in src/lib/. Ensures both caller and callee are verified before state:ready-for-qa.
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
Activate this lens when a ticket changes a Supabase database function (RPC), edge function, or the TypeScript client layer. Contract breaks at the boundary between SQL and TypeScript are the most common source of bugs that pass unit tests but fail in Tester's end-to-end verification.
Load this lens when the ticket changes any of the following:
CREATE OR REPLACE FUNCTION)supabase/functions/)src/lib/supabase.ts, src/lib/adminApi.ts, src/lib/stripe.ts, or any src/lib/*.ts)supabase.rpc() or a Supabase edge function directlysrc/types/database.ts or equivalent)For each changed contract surface, verify both sides before claiming done. Cross-layer claims require cross-layer proof — confirming one side only is not sufficient.
| Check | What to verify |
|---|---|
| Parameter names and types | SQL function parameter names and types match exactly what the TypeScript caller passes to supabase.rpc() or the edge function fetch |
| Return shape | SQL RETURNS type, RETURNS TABLE columns, or JSON response shape matches the TypeScript type that consumes the result |
| Error contract | SQL raises an exception (RAISE EXCEPTION) on known failure conditions in a way TypeScript can classify — not returning null silently |
| Nullable fields | SQL columns that can be NULL correspond to optional (?) fields in the TypeScript type — no silent null becoming undefined mismatch |
| RLS | Row-level security policies on affected tables still permit the calling role's operations after the change |
| Check | What to verify |
|---|---|
No any shortcuts | The RPC response or edge function response is typed with a concrete type, not widened to any or unknown without explicit narrowing at the callsite |
| Error path handled | The .error branch from supabase.rpc() or the edge function fetch is handled — surfaced to the UI, thrown, or logged — not silently swallowed |
| Caller is reachable | The updated client function is actually called from the correct component or hook; no dead code path where the old contract remains in use |
| Types compile | If a shared type in src/types/ was updated, all consumers compile without @ts-ignore or as any suppressions |
| Auth header | If the edge function requires the user's JWT, the caller passes Authorization: Bearer <token> correctly |
Before implementation, name the specific contract surface this ticket touches:
Contract surface: [supabase.rpc('function_name') | supabase/functions/name | src/lib/file.ts:functionName]
Direction of change: [SQL only | TypeScript only | both sides]
A ticket that only touches the TypeScript side (no SQL change) still needs the TypeScript checklist — it may introduce a type mismatch against an unchanged SQL contract.
Before moving the ticket to state:ready-for-qa, post the following confirmation on the GitHub issue:
CSV verified:
- Contract surface: [name]
- SQL side: [parameter shape ✓ | return shape ✓ | error contract ✓ | n/a]
- TypeScript side: [typed correctly ✓ | error handled ✓ | caller reachable ✓ | types compile ✓]
If the ticket only touches one side, note which side was verified and why the other is unaffected. Tester will attempt to exercise the contract end-to-end; a contract that looks correct in isolation can still fail when both sides interact.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Universal guardrails loaded by every agent. Defines Verify Before Reporting (VBR), Write-Ahead Log (WAL), and the security baseline. Always-on, role-independent.
The English summary is being prepared. Showing the original description.
Use when: architecture mode, architect this, ADR, C4, PlantUML, system boundary, design decision, PRD gap, high ambiguity, multiple technical approaches, security architecture, data architecture, integration risk, implementability gap, story ticket, or epic ticket.
The English summary is being prepared. Showing the original description.
Use when: assumptions audit, audit assumptions, check for hidden assumptions, plan/ticket has ambiguous scope edges, pre-flight before finalizing a ticket, unstated assumptions, or 'what am I assuming'. Surfaces unstated assumptions, ambiguous scope edges, and untested preconditions in a finished plan/ticket/ADR before it is handed to Builder. Optional pass — Architect judges when to apply it; not a mandatory gate on every ticket.
The English summary is being prepared. Showing the original description.
Use when: Tester needs UI state evidence for VBR, or Builder needs to verify an integration wire is observable end-to-end. Powered by agent-browser MCP — token-efficient browser automation (200–400 tokens/page).
The English summary is being prepared. Showing the original description.
Use when drafting a bug or defect ticket, reviewing one someone else wrote, or deciding whether a reported problem is ready to file. Keeps what the reporter actually saw separate from what the agent later found out, so a reader can tell which lines are testimony and which are collected proof. Trigger phrases: 'file a bug', 'write up this defect', 'triage this report', 'is this ticket ready to file', 'what did the reporter actually see'.
The English summary is being prepared. Showing the original description.
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
The English summary is being prepared. Showing the original description.