Current-work packets — steps

Record status

Record ID

field-guide:current-work-packets

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. Open the Field Guides surface and confirm this proposal is being used as a bounded local procedure; do not treat the named route as proof of connected web behavior.
2. Open Today and state the packet’s current purpose, owner, related job, and intended completion boundary.
3. Create or inspect the source-labelled note in Notes. Record canonical ID, origin, source locator, source SHA-256, provenance, revision, lifecycle, tags, links, and any known gaps.
4. Add local file references in Files when supporting material is needed. Inspect type and size, link each reference to the packet, and leave upload or protected-storage effects held.
5. Break the work into ordered to-dos. Give every actionable item an owner, priority, explicit dueAt, completion state, dependency, and human-review signal. Use recurrence only when it is explicitly a candidate rather than hidden automation.
6. Review the workback in Agenda as a draft schedule. Check time blocks and conflicts, but do not write to an external provider or imply calendar synchronization.
7. Use PointGuard to keep the current packet context visible while moving among Notebook surfaces. Treat specialist surfaces as execution and canonical-record owners; PointGuard is contextual, not the canonical owner.
8. Collect evidence and record each item’s source locator, provenance, revision, and custody state. Mark missing, contradictory, or stale evidence as a gap rather than filling it by inference.
9. Open Approvals and set the packet to Needs review. A reviewer must inspect scope, evidence, deadlines, authority boundaries, accessibility of the records, and failure branches.
10. If the reviewer accepts the bounded proposal, mark it Approved locally and preserve the decision rationale and receipt reference. Approval does not authorize external send, deployment, provider writes, credential use, publication, customer indexing, or production effects.
11. If evidence, ownership, deadlines, or authority are unclear, mark the packet Held, record the hold reason, create a follow-up to-do, and stop the affected branch.
12. Record the handoff in Agent Logs with current work, authority boundaries, receipt, and state. Link the log to the packet and related to-dos.
13. Return to Today and verify that completed work, due items, open loops, and held branches are visible. Reconcile any changed records through revision history.

Deadline and chronology rules

• Every actionable step must have an explicit due date and time before it is treated as scheduled.
• Use priority and dependency fields to distinguish urgent work from blocked work.
• A missing owner, due date, or dependency moves the item to Needs review or Held; it must not be silently scheduled.
• Use recurrenceCandidate only as a reviewable proposal, never as hidden automation.
• When a deadline changes, preserve the prior revision and record the reason for change.
• External calendar, message, provider, credential, database, customer, publication, and production effects remain held.

Failure branches during execution

• A named native route may be mistaken for a connected web feature.
• A local approval may be mistaken for authorization to create external effects.
• Unlabelled evidence can lose provenance or become detached from the canonical record.
• Missing deadlines or owners can turn a workback into hidden automation or an unowned queue.
• Conflicting revisions can produce an unsafe handoff if the latest source state is not inspected.
• File references may imply upload or protected custody when those effects are held.
• Agent context may be mistaken for specialist-app canonical ownership.
• Accessibility failures can hide Held, Needs review, or deadline states from keyboard or assistive-technology users.

Sources and evidence

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

• source_record:field-guide:current-work-packets
• agents/index.html#stan
• 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/today/
• App route: /app/notebook/notes/
• App route: /app/notebook/files/
• App route: /app/notebook/to-dos/
• App route: /app/notebook/agenda/
• App route: /app/notebook/approvals/
• App route: /app/notebook/agent-logs/
• App route: /app/pointguard/
• Source record: field-guide:current-work-packets
• ALLOWED_INSTRUMENTS directory: no instrument selected