Receipt-backed handoffs — field guides

Record status

Record ID

job:stan:receipt-backed-handoffs

Parent lifecycle

candidate

Page lane

docs_urls

Lane lifecycle

proposed

Owner

Stan

Owner role

Chief Security and Engineering Officer

Owner status

VERIFIED

Qualification result

NOT RUN · held for evidence and human review

Working browser surface: Agent jobs — builder overview — Inspect the package and stage a local project. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held.

Related field-guide records

• /app/notebook/field-guides/

Source-proposed guide paths are references, not proof that those paths resolve.

Operating sequence

1. Receive and normalize the handoff request.
2. Bind the request to canonical source records, locators, revisions, and available provenance.
3. Separate preparation from execution and enumerate the requested effects.
4. Run the Assurance preflight for scope, evidence, security, reversibility, and missing inputs.
5. Classify principal gates, including destructive remediation, money or purchasing, credential changes, public deployment, and legal filing.
6. Prepare the current-work packet and ordered handoff checklist.
7. Record explicit failure states and escalation conditions rather than filling gaps with assumptions.
8. Route the proposal to the appropriate human approval surface when a gate is present.
9. Create a receipt ledger entry containing source references, packet contents, status, and held effects.
10. Place unresolved work, deadlines, and continuity notes into Notebook surfaces for review.
11. Close only when the recipient, evidence, acknowledgement, and remaining authority boundary are recorded; otherwise mark the handoff held.

Handoff boundary

• Treating confidence, urgency, or a prior handoff as permission.
• Manufacturing Antonio's authority or substituting Stan's role for a required approver.
• Converting a proposal, terminal instruction, or receipt into an external effect.
• Executing destructive remediation or changing credentials without explicit human authorization.
• Leaking secrets, credentials, sensitive paths, or protected operational details into a handoff.
• Using stale, unverified, or unprovenanced source material.
• Creating a receipt that records intention as completion.
• Assuming a named Supabase or Cloudflare guide proves provider connection or operational access.
• Overlooking recipient identity, acknowledgement, timezone, dependency, rollback, or continuity requirements.
• Relying on inaccessible status colors, ambiguous labels, or undocumented failure states.

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• agents/index.html#stan
• source_record:job:stan:receipt-backed-handoffs
• observed_native_contract.records
• observed_native_contract.deadlines
• observed_native_contract.pointguard
• observed_native_contract.web_boundary
• app_route:/app/pointguard/
• app_route:/app/notebook/approvals/
• app_route:/app/notebook/agent-logs/
• app_route:/app/notebook/field-guides/
• app_route:/app/notebook/projects/
• app_route:/app/notebook/search/
• job:stan:receipt-backed-handoffs
• Observed native contract: records preserve canonical IDs, provenance, revisions, lifecycle, links, attachments, and receipt-related evidence
• Observed native contract: PointGuard is a persistent cross-app context surface while specialist apps remain execution and canonical-record owners
• Observed app route: /app/pointguard/
• Observed app route: /app/notebook/agent-logs/
• Observed app route: /app/notebook/approvals/
• Observed app route: /app/notebook/messages/
• Observed app route: /app/notebook/search/