user-feedback: steer repeated gated failures to project-scoped MCP and validator-first recovery

Start with skills/supabase/SKILL.md and read Core Principles > 3. Recover from errors, don't loop and Supabase MCP Server > Troubleshooting connection issues. Add the requested escalation checklist after the second failure, covering state classification, project scoping, validator checks, durable mutations, and delta-only reads; done means each of the five recovery behaviors is documented without changing the workflow itself.

What happened

Task: Safely bootstrap and verify an isolated Supabase staging project, apply a migration once, and run a bounded Auth/Data API lifecycle under strict provider-call ceilings.

Skill said: The Core Principles say to recover rather than loop after 2–3 failures, and the MCP section explains reachability/authentication, but it does not give a concrete escalation pattern for (a) repeated failures caused by an unscoped/general MCP tool contract, or (b) validator-query defects discovered only after a one-time migration or scarce read call is consumed.

Expected: After the second substantive gate failure, guidance should direct the agent to classify the blocker as product state vs access/scoping/tool contract/parser/validator/prompt sequencing; prefer a dedicated project-scoped MCP namespace with explicit read-only/write boundaries; validate catalog predicates against the exact object-resolution primitive before consuming remote call budgets; and resume from the highest durable completed layer instead of replaying successful preflights, dry-runs, or pushes.

A concrete failure pattern: a migration was successfully applied, but a frozen structural query compared pg_get_function_identity_arguments(oid) to type-only text and returned count 0, while the same query successfully resolved the exact regprocedure OID for search-path and privilege checks. The safe response is a corrected SELECT-only read-back plus continuation—not another migration attempt or a full reset of the workflow.

The user reports that repeated fail-closed packet/tool/validator rounds consumed substantial time and tokens and delayed launch work.

Source

File: skills/supabase/SKILL.md

Section: Core Principles > 3. Recover from errors, don't loop and Supabase MCP Server > Troubleshooting connection issues

Fix suggestion

Add a short root-cause escalation checklist after the second failure:

1. Classify database state separately from access, project scoping, read-only enforcement, tool schema, result parser, validator SQL, and prompt sequencing.
2. For live work, prefer a dedicated project-scoped MCP connection; do not treat caller-supplied project IDs as provider-enforced scope.
3. Before a scarce remote validation call, locally/static-validate catalog predicates and use OID/to_regprocedure identity checks rather than formatting-sensitive text where possible.
4. When a mutation has durably succeeded but validation is defective, freeze that state and authorize only a corrected read-back/continuation. Do not replay the mutation.
5. Encourage delta-only source reads and evidence reuse to avoid repeatedly rereading large migrations and packets.