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

project template / candidate

Website surface — deadlines

The distinct deadlines record for Website surface. This page is proposal-only.

Status: proposedLifecycle: candidate

Record status

Record ID
project:website-surface
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.

Deadline and workback rules

  • A target release date is required before a release workback can be approved.
  • Every milestone must have an owner, planned finish date, acceptance criteria, and evidence requirement.
  • Every deadline must identify an owner and a late action; overdue items remain visible until resolved or explicitly rescheduled.
  • Review deadlines must precede the release gate by enough time for documented remediation; the exact buffer is a project field, not an inferred system default.
  • A blocked dependency automatically holds dependent milestones and release approval until an owner records resolution or an approved exception.
  • Claims without source-labelled evidence remain held and cannot be marked approved.
  • Accessibility, crawl, claim, and release gates must each have a recorded decision; absence of a decision is Needs review.
  • External provider writes, credential use, database authority, customer indexing, publication, and production effects remain held.
  • Closure cannot mark the project complete while required approvals, evidence, or blocking risks remain unresolved.
  • Every project must have one target review or release date before a workback can be generated.
  • Every milestone must have a due date, owner, priority, and completion state.
  • A milestone cannot be marked complete while required dependencies are incomplete.
  • Accessibility remediation due dates must not be later than the target review date unless explicitly marked held.
  • Overdue items appear in Today and remain visible until completed, rescheduled, or held with a reason.
  • Agenda changes are drafts only; no calendar provider write, invitation, notification, or external scheduling effect occurs.
  • Changing the target date preserves the prior workback revision and creates a new deterministic revision.
  • Dates require an explicit timezone and invalid or ambiguous dates produce an inline error.

Workback sequence

  1. Create the project record and assign a human owner.
  2. Define proposed pages, routes, audience, and local scope.
  3. Add source-labelled claim records; mark unsupported or uncertain claims as held.
  4. Draft page content in Paper and link each draft to its project, claims, and source notes.
  5. Add file references for local assets without hidden upload or protected-storage assumptions.
  6. Create crawl review items for every proposed navigational and external link.
  7. Run the local accessibility checklist and record test results, evidence, owners, and due dates.
  8. Use the WCAG contrast instrument for contrast checks and retain its result as a linked review record.
  9. Set the target review or release date and generate a workback of local milestones.
  10. Review deadlines, conflicts, overdue items, and incomplete gates in Today and Agenda.
  11. Submit the assembled proposal to Approvals; preserve approval, hold, or needs-review receipts.
  12. Show the final release summary as proposal-only, with publication, hosting, provider writes, indexing, and customer effects explicitly held.

Scheduling records

  • milestone records
  • deadline to-dos
  • dependency records
  • owner assignments
  • workback record
  • workback milestones

Sources and evidence

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

  • source_record:project:website-surface
  • NotebookCollectionKind.project
  • NotebookTodoPayload.dueAt
  • Notebook Agenda deadlines/workbacks
  • Observed native contract: project_and_field_guide_collections
  • Observed native contract: deadlines
  • Observed native contract: records
  • Observed native contract: pointguard
  • Observed native contract: web_boundary
  • APP_ROUTES:/app/notebook/projects/
  • APP_ROUTES:/app/notebook/to-dos/
  • APP_ROUTES:/app/notebook/agenda/
  • APP_ROUTES:/app/notebook/approvals/
  • APP_ROUTES:/app/notebook/notes/
  • APP_ROUTES:/app/notebook/files/
  • APP_ROUTES:/app/notebook/field-guides/
  • APP_ROUTES:/app/notebook/search/
  • APP_ROUTES:/app/pointguard/
  • project:website-surface
  • Notebook records provenance and revision contract
  • PointGuard persistent cross-app context surface
  • APP_ROUTES:/app/notebook/paper/
  • ALLOWED_INSTRUMENTS:wcag-contrast-ratio-checker
  • ALLOWED_INSTRUMENTS:reading-time-estimator