World packets — steps

Record status

Record ID

field-guide:world-packets

Parent lifecycle

candidate

Page lane

plan

Lane lifecycle

proposed

Owner

Wick

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 a proposed world packet in Notebook Field Guides or Projects and assign Wick as owner agent; record the related jobs exactly as supplied.
2. Define scope, audience, visibility, target completion date, and exclusions. Mark all external effects as held.
3. Create a source register in Notes and Files for every supplied source locator or local reference. Preserve canonical ID, origin, locator, source SHA-256 when available, provenance, revision, lifecycle, tags, links, and attachments.
4. Create a research to-do with dueAt and priority. Work backward from the target completion date: finish source capture first, research review next, dossier and draft preparation next, human approval before any proposed send, and final chronology review last.
5. Record world-post research as source-labelled observations. Separate observed facts, interpretation, unknowns, and follow-up questions.
6. Assemble the outreach dossier from reviewed research. Map each proposed claim or personalization note to a source record and explicitly list claims that must not be made.
7. Prepare a message draft in Notebook Messages. Include recipient, purpose, source context, requested action, attachments, send-by deadline, and a visible note that final send remains human-held.
8. Create an approval record with Needs review, Approved, or Held state. Preserve the proposal and receipt; do not treat local approval as delivery or publication.
9. Record response triage only from an identified observation or supplied response reference. Do not infer provider ingestion, customer indexing, or receipt when no evidence exists.
10. Append each material event to campaign chronology with date or time, actor, linked record, provenance, and uncertainty note.
11. Run the completion review: verify required records, source mappings, deadlines, open loops, accessibility, and failure states. Mark the packet complete only as a local record state; keep external effects held.
12. Create a review to-do for stale sources, approaching deadlines, unanswered responses, and any revised claims. Preserve revisions rather than overwriting prior evidence.

Deadline and chronology rules

• Require a target completion date before research begins.
• Set source-capture dueAt before research-review dueAt; set dossier and draft deadlines before approval deadline.
• Set a send-by deadline on every message draft, but keep final send held until human approval and a verified execution surface exist.
• Set response-triage dueAt based on recorded urgency; if urgency is missing, route to human review rather than guessing.
• Create a stale-source review when a source is revised, unavailable, or missing provenance.
• If any deadline passes, mark the to-do overdue, preserve the prior state, create a revised dueAt, and record the reason.
• Do not schedule recurring external actions; recurrenceCandidate may be used only as a review signal for local maintenance.

Failure branches during execution

• A named agent or route may be mistaken for an active connected service; label all surfaces as local prototypes or indexes where applicable.
• Research may drift into unsupported world or recipient claims; require source mapping and explicit unknowns.
• Draft approval may be mistaken for message delivery; preserve the human-held boundary.
• A response reference may be incomplete or second-hand; record observation provenance and route ambiguity to review.
• Stale, conflicting, or revised sources can invalidate a dossier; preserve revisions and reopen affected claims.
• Sensitive recipient context may be over-collected; capture only fields necessary for the stated outreach purpose and respect visibility partitions.
• Deadline automation may be inferred from recurrenceCandidate or scheduled views; use them only as local review signals.
• Distinct documentation pages must contain useful procedure content; do not create doorway or keyword-spam pages.
• Instrument selection is intentionally empty because the supplied packet workflow has no verified calculation requirement.

Sources and evidence

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

• source_record:field-guide:world-packets
• agents/index.html#wick
• observed_native_contract:project_and_field_guide_collections
• observed_native_contract:deadlines
• observed_native_contract:records
• observed_native_contract:pointguard
• app_route:/app/notebook/field-guides/
• app_route:/app/notebook/notes/
• app_route:/app/notebook/files/
• app_route:/app/notebook/to-dos/
• app_route:/app/notebook/messages/
• app_route:/app/notebook/approvals/
• app_route:/app/notebook/agent-logs/
• app_route:/app/notebook/projects/
• app_route:/app/pointguard/