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

project template / candidate

Apple platform feature — deadlines

The distinct deadlines record for Apple platform feature. This page is proposal-only.

Status: proposedLifecycle: candidate

Record status

Record ID
project:apple-feature
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

  • Every project must have a proposed target outcome date or explicitly state that the date is not yet known.
  • Every milestone must have an owner, planned finish date, predecessor or explicit no-predecessor declaration, and exit criteria.
  • Evidence capture and review deadlines must precede the approval deadline by a recorded review window.
  • A blocked milestone must have a blocking dependency, owner, next review date, and fallback or escalation note.
  • Changes to target dates or milestone dates must create a revision note and preserve the prior value.
  • Hard deadlines must not be silently moved; replanning requires an approval or held decision record.
  • A recurring to-do is only a candidate until a human reviews and confirms the recurrence.
  • External calendar, provider, credential, database, customer, publication, and production writes remain held unless separately verified.
  • Target qualification date is required before a qualification workback can be generated.
  • Every derived checkpoint must retain its source target date, offset, timezone, and revision.
  • Default workback offsets are proposals only and must be editable: evidence cutoff 2 business days before qualification, accessibility review 3 business days before qualification, device testing 5 business days before qualification, implementation complete 8 business days before qualification.
  • A checkpoint with no dueAt is shown as unscheduled, never silently assigned a date.
  • Past-due incomplete items are marked overdue; completed items retain their original dueAt and completion timestamp.
  • Changing the target date previews affected dates before saving and records a revision.
  • Conflicting or impossible dates are surfaced as a blocking validation error with the conflicting records named.
  • External calendar creation, reminders, messages, notifications, deployment, entitlement changes, and release publication remain held.

Workback sequence

  1. Create the project record with a canonical ID, owner, lifecycle, and target outcome.
  2. Record the native platform, device families, OS range, capability or entitlement dependency, and simulator/device boundary.
  3. Define in-scope behavior, explicit exclusions, accessibility requirements, privacy-sensitive data, and expected failure states.
  4. Add source-labelled notes and local file references; preserve provenance, revisions, links, and attachments without implying upload or protected-storage completion.
  5. Enter the qualification and release decision dates; generate workback to implementation, device testing, accessibility review, evidence cutoff, and approval checkpoints.
  6. Create linked to-dos with dueAt, priority, tags, completion state, and review status.
  7. Open the project in PointGuard to project current work, blockers, due items, linked records, and held decisions.
  8. Run local interface, unit, device, failure-state, accessibility, and regression checks; attach or link evidence records.
  9. Submit the qualification proposal for local approval; preserve the decision, reviewer, timestamp, and receipt.
  10. Mark unresolved entitlement, provider, credential, publication, deployment, or production actions as Held rather than executing them.

Scheduling records

  • milestone records
  • deadline and workback to-dos
  • dependency records
  • owner assignments
  • Implementation task records

Sources and evidence

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

  • source_record:project:apple-feature
  • NotebookCollectionKind.project
  • NotebookTodoPayload.dueAt
  • Notebook Agenda deadlines/workbacks
  • Notebook records canonical IDs, provenance, source locators, source SHA-256, revisions, lifecycle, tags, links, and attachments
  • PointGuard persistent cross-app context surface
  • APP_ROUTES:/app/notebook/projects/
  • APP_ROUTES:/app/notebook/to-dos/
  • APP_ROUTES:/app/notebook/agenda/
  • APP_ROUTES:/app/notebook/files/
  • APP_ROUTES:/app/notebook/approvals/
  • APP_ROUTES:/app/notebook/field-guides/
  • APP_ROUTES:/app/notebook/agent-logs/
  • APP_ROUTES:/app/pointguard/
  • Notebook records provenance and revision contract
  • Current GuthHub app routes and held external-effect boundary