Source: https://guthlabs.ai/docs/field-guides/supabase-field-guide/steps/ field guide / candidate # Supabase field guide โ€” steps The distinct steps record for Supabase field guide. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: field-guide:supabase-field-guide **Parent lifecycle**: candidate **Page lane**: plan **Lane lifecycle**: proposed **Owner**: Stan **Owner role**: Not separately recorded **Owner status**: Not separately recorded **Qualification result**: NOT RUN ยท held for evidence and human review **Working browser surface:** [Field guides โ€” documentation]() โ€” Inspect the guide and persist local checkpoints. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held. ## Ordered procedure - 1. Create or open the proposed field-guide record in Notebook Field Guides and set lifecycle to proposed; record Stan as owner and link the supplied related jobs. - 2. Copy the supplied source reference agents/index.html#stan and source record identifier into the provenance section; preserve any available locator, source SHA-256, revision, and origin rather than replacing them with assumptions. - 3. Define the review question and explicitly list held effects: provider connection, credentials, database authority, customer indexing, publication, deployment, and production writes are not established by the named Supabase surface or by any observed route. - 4. Map each proposed concern to an accountable review lane: security engineering for access and credential boundaries, architecture and implementation for component ownership, SRE and incident command for failure handling, fleet operations for operational procedures, and receipt-backed handoffs for evidence transfer. - 5. Draft an architecture note describing only proposed boundaries. Treat PointGuard as contextual navigation and preserve specialist-app ownership of execution and canonical records; do not assign canonical ownership to PointGuard. - 6. Use Notebook Notes for source-labelled analysis and Notebook Files for local file references. Do not imply hidden upload or protected storage; if a source artifact is unavailable, record the absence as an evidence gap. - 7. Create bounded to-dos for each review lane with an explicit due date, priority, owner, tags, and human-review signal. Use Agenda only to draft or inspect local schedule information; external calendar effects remain held. - 8. Record security checks covering credential non-disclosure, least-privilege assumptions, visibility partitioning, provenance preservation, and explicit rejection of unsupported production claims. - 9. Record operational checks covering failure states, incident ownership, rollback or hold behavior, receipt preservation, and what evidence would be required before any future implementation decision. - 10. Run a human review in Notebook Approvals. Mark the proposal Needs review until evidence and ownership are complete; use Held when a required fact, receipt, or authority boundary is missing. - 11. Prepare a receipt-backed handoff containing the field-guide ID, source references, linked notes and files, completed checks, unresolved questions, deadline state, and approval state. Do not describe the handoff as deployment or provider connection. - 12. Mark the guide complete only when all acceptance tests pass; otherwise retain proposed lifecycle and create a failure or follow-up record. ## Deadline and chronology rules - Set a target review date before beginning lane reviews; if no date is supplied, keep the guide proposed and record the missing deadline rather than inventing a calendar date. - Create one to-do per review lane with an owner, priority, dueAt, and review tag. - Set lane due dates no later than the target review date; create a final handoff review due date after all lane checks. - If any lane misses its due date, mark the related to-do incomplete or Held, record the reason, and do not mark the guide complete. - Agenda entries may draft local workback blocks only; no external calendar write or provider-side scheduling is implied. ## Failure branches during execution - A named Supabase surface may be mistaken for a connected provider feature. - Prototype or indexed routes may be mistaken for production behavior. - Unverified credentials, database authority, customer data, publication, or deployment may be inferred from architecture language. - PointGuard may be incorrectly treated as the canonical execution or record owner. - Missing provenance, source hashes, or receipts may make later review non-reproducible. - Relative deadlines may be misread as committed calendar dates if no target date is supplied. - Security, incident, or operational conclusions may be overstated when the supplied source record contains no implementation evidence. - Local drafts, approvals, or schedule entries may be mistaken for external side effects. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:field-guide:supabase-field-guide` - `agents/index.html#stan` - `field-guide:supabase-field-guide:plan` - `Observed native contract: project_and_field_guide_collections` - `Observed native contract: deadlines` - `Observed native contract: records` - `Observed native contract: pointguard` - `Observed app routes supplied in the source context`