Supabase field guide — steps

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. 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. 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. 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. 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. 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. 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. 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. 8. Record security checks covering credential non-disclosure, least-privilege assumptions, visibility partitioning, provenance preservation, and explicit rejection of unsupported production claims.
9. 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. 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. 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. 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