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

project template / candidate

Social campaign — field guides

The distinct field guides record for Social campaign. This page is proposal-only.

Status: proposedLifecycle: candidate

Record status

Record ID
project:social-campaign
Parent lifecycle
candidate
Page lane
app_features
Lane lifecycle
proposed
Owner
Not separately recorded
Owner role
Not separately recorded
Owner status
Not separately recorded
Qualification result
NOT RUN · held for evidence and human review

Working browser surface: Project templates & workflows — overview — Create a local project from this template and validate its forms. 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. Create the project record with a canonical ID, provenance, source references, lifecycle, owner, and revision metadata.
  2. Complete campaign intake and identify the accountable approver before drafting begins.
  3. Set scope, deliverables, exclusions, accessibility requirements, and definitions of ready and done.
  4. Create milestone and deadline records using dueAt, priority, completion state, tags, and revision notes.
  5. Build the workback from the hard deadline, including review, approval, accessibility, and buffer time.
  6. Register dependencies, owners, fallback plans, and escalation rules.
  7. Declare the local tools, guides, and canonical record owners for each work item.
  8. Draft messages or documents in the appropriate local surface and link each draft to its source context.
  9. Collect source-labelled evidence and record measurement definitions without presenting unsupported live metrics.
  10. Submit the exact revision for fact, policy, accessibility, and owner review.
  11. Record approval, held, or needs-review decisions with receipts; keep final send and publication human-held.
  12. Review slippage, risks, and dependency changes at each milestone and revise affected deadlines explicitly.
  13. Close only after deliverables, evidence, approvals, held actions, and follow-up ownership are recorded.

Handoff boundary

  • Treating a named route as proof of a connected web feature or production backend.
  • Publishing or sending externally without human approval of the exact revision.
  • Unsupported performance, audience, customer, or live-metric claims based on incomplete evidence.
  • Deadline drift caused by missing timezone, hidden recurrence, unowned dependencies, or silent reforecasting.
  • Accessibility review being treated as optional or performed only after approval.
  • Private campaign notes, recipient information, or attachments crossing visibility boundaries.
  • Using drafts, agenda entries, or receipts as evidence that an external action occurred.
  • Closure being used to conceal held deliverables, unresolved risks, or missing evidence.

Sources and evidence

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

  • source_record:project:social-campaign
  • project:social-campaign
  • NotebookCollectionKind.project
  • NotebookTodoPayload.dueAt
  • Notebook records provenance and revision contract
  • Notebook Agenda deadlines/workbacks
  • /app/notebook/projects/
  • /app/notebook/to-dos/
  • /app/notebook/agenda/
  • /app/notebook/messages/
  • /app/notebook/approvals/
  • /app/notebook/paper/
  • /app/notebook/field-guides/
  • /app/pointguard/
  • Notebook records provenance, source locators, SHA-256, revisions, lifecycle, tags, links, and attachments
  • Observed web boundary: provider, credential, database, customer, publication, and production effects are held