Response triage — field guides

Record status

Record ID

job:wick:response-triage

Parent lifecycle

candidate

Page lane

docs_urls

Lane lifecycle

proposed

Owner

Wick

Owner role

World posts and outreach agent

Owner status

HELD

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. Open the source-linked request in PointGuard or Notebook and preserve its canonical record identifiers.
2. Acquire or reference the applicable World packet, Outreach rules, Account dossier, and Contact history; if any required source is missing, mark the item Needs review rather than filling the gap.
3. Apply the Response classifier to identify intent, urgency, tone, commitments, pricing content, access implications, and identity risks.
4. Use Source lock to distinguish verified facts, unresolved conflicts, and unknowns; do not infer relationship history or account permissions.
5. Select a proposed response path: draft reply, draft world post, request clarification, escalate to Antonio, or hold.
6. Prepare a source-linked draft with recipient or audience, route label, attachments, and explicit uncertainty notes.
7. Run the principal-gate checklist for external send, relationship commitments, pricing statements, account access, and identity representation.
8. Create a human-review receipt and set a review deadline; retain the draft as held until a human approves it.
9. If approved locally, preserve the approval and revision receipt while keeping final send, publish, and external writes human-held.
10. On rejection, expiry, source conflict, unverified route, or missing evidence, record the failure state and return the item to clarification or hold.

Handoff boundary

• Impersonating Antonio or implying personal authorship without approval.
• Sending from an unverified route or treating a route label as proof of connectivity.
• Inventing relationship history, account facts, commitments, or customer context.
• Turning a local prototype route into a claim of provider connection or external effect.
• Publishing world posts or sending outreach without a human gate.
• Including unsupported pricing, availability, promises, or legal/commercial commitments.
• Using account access, credentials, or protected customer data outside the job boundary.
• Losing source provenance, canonical IDs, revisions, or the exact approved draft.
• Treating classifier output as authorization rather than bounded assistance.
• Creating doorway documentation routes without distinct useful procedural content.

Sources and evidence

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

• agents/index.html#wick
• source_record:job:wick:response-triage
• observed_native_contract:records
• observed_native_contract:pointguard
• observed_native_contract:deadlines
• app_route:/app/notebook/messages/
• app_route:/app/notebook/approvals/
• app_route:/app/notebook/agent-logs/
• app_route:/app/notebook/field-guides/
• Observed native contract: Notebook records preserve canonical IDs, provenance, revisions, lifecycle, tags, links, attachments, and record revisions.
• Observed native contract: PointGuard is a persistent cross-app context surface; specialist apps remain execution and canonical-record owners.
• Observed native contract: current GuthHub app routes are local prototypes or indexes and provider, credential, database, customer, publication, and production effects are held.
• App route: /app/notebook/messages/
• App route: /app/notebook/approvals/
• App route: /app/notebook/agent-logs/
• App route: /app/pointguard/