Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

field guide / candidate

Channel rules — steps

The distinct steps record for Channel rules. This page is proposal-only.

Status: proposedLifecycle: candidate

Record status

Record ID
field-guide:channel-rules
Parent lifecycle
candidate
Page lane
plan
Lane lifecycle
proposed
Owner
Rebecca
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. Open the field guide from Notebook Field Guides and confirm the record is marked proposed; do not treat the named guide or route as evidence of a connected social feature.
  2. 2. Confirm Rebecca as the owner and preserve the supplied source reference agents/index.html#rebecca. Record the related jobs: Social planning, Draft preparation, Asset coordination, Approval routing, and Post-performance records.
  3. 3. Create or link a source-labelled note that states the planning objective, intended channels, known constraints, unresolved questions, and the boundary that provider, credential, customer, publication, and production effects remain held.
  4. 4. For each channel, enter only rules supported by an available source record or explicitly mark the rule as unknown and requiring confirmation. Add an owner, source locator, review-by date, and revision note.
  5. 5. Create a draft for each intended channel. Link every draft to its channel rule records, source notes, and proposed timing. Keep final send or publication as a human-held action in Notebook Messages or Approvals.
  6. 6. Add local file references for required assets in Notebook Files. Inspect type and size, link each reference to the draft, and provide an accessibility description. Do not imply upload, protected storage, or provider delivery.
  7. 7. Run a pre-approval checkpoint: verify source traceability, channel-rule coverage, draft completeness, asset references, accessibility text, audience, timing, and unresolved hazards.
  8. 8. Create an approval proposal in Notebook Approvals with reviewer, decision deadline, source context, and the exact external effect being held. Preserve the local approval receipt for any decision.
  9. 9. If approved locally, retain the draft as approved for review purposes only. Do not claim that it was sent, published, indexed, delivered, or accepted by a provider.
  10. 10. After a human supplies a post-performance observation, create a source-labelled performance record with metric source, locator, date, and provenance. If no verified observation exists, record that performance data is unavailable rather than estimating it.
  11. 11. Create or update bounded to-dos for unresolved rules, missing assets, approval follow-up, and post-performance review. Use due dates, priorities, tags, completion state, and revision history.
  12. 12. Mark the guide complete only when all acceptance tests pass; otherwise keep it proposed or place the affected work on hold with a recorded reason.

Deadline and chronology rules

  • Every channel rule must have a review-by date or be explicitly marked undated and held for confirmation.
  • Draft preparation must complete before the approval decision deadline.
  • Asset review must complete before approval routing; missing or inaccessible assets force a hold.
  • Post-performance review should be scheduled after a supplied observation date; no live metric deadline may be inferred.
  • Overdue items remain open and visible in Today or To-dos until a human updates their state.

Failure branches during execution

  • A channel rule may be invented or generalized without source evidence.
  • A native route may be mistaken for a connected social provider or publication system.
  • A draft may be treated as sent or published after local approval.
  • Unverified metrics may be copied into post-performance records as if live data.
  • Asset references may imply upload, protected storage, rights clearance, or delivery when those states are not verified.
  • Missing accessibility descriptions may block review or reduce usability.
  • Undated rules and approvals may become stale without a review-by date.
  • Private notes, assets, approvals, and public-facing context may be mixed without visibility checks.

Sources and evidence

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

  • source_record:field-guide:channel-rules
  • agents/index.html#rebecca
  • observed native contract: project_and_field_guide_collections
  • observed native contract: deadlines
  • observed native contract: records
  • observed native contract: pointguard
  • /app/notebook/field-guides/
  • /app/notebook/agent-logs/
  • /app/notebook/approvals/
  • /app/notebook/messages/
  • /app/notebook/files/
  • /app/notebook/notes/