Customer implementation — deadlines

Record status

Record ID

project:customer-implementation

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 milestone must have an owner, due date, predecessor or explicit no-predecessor declaration, expected evidence, and acceptance condition.
• Every deadline must use dueAt when a date and time are known; date-only deadlines must state the assumed timezone or calendar convention.
• Workback dates must be calculated backward from the target completion date and must include review, evidence, approval, and contingency buffers.
• A blocked dependency must create or link to a deadline todo and identify an escalation owner.
• Late or missed deadlines must remain visible, preserve their revision history, and require a replan reason rather than silent date changes.
• Recurring work must be marked only as a recurrence candidate until a human confirms the recurrence pattern.
• External calendar writes, customer notifications, final sends, provider actions, credential use, publication, and production changes remain held for human review.
• Every milestone must have an explicit dueAt or be marked undated with a reason.
• A milestone cannot be marked ready for review if a required predecessor is incomplete or missing.
• Workback dates are deterministic from target completion date, task duration, dependency order, and review buffer; assumptions are shown beside results.
• Conflicting deadlines are surfaced before saving a schedule change.
• Past-due items remain visible and are not silently rescheduled.
• Recurrence is only a candidate flag and never creates hidden automation.
• Date-only inputs must define timezone behavior before conversion to dueAt.
• External calendar writes and notifications remain held.

Workback sequence

1. Create the project record and assign a unique canonical ID.
2. Enter the customer display name, tenant label, visibility, scope, and out-of-scope boundaries.
3. Define the desired configuration outcome and evidence required for acceptance.
4. Add milestones with explicit dueAt values, priorities, owners, estimates, and predecessor links.
5. Generate a local workback from the target completion date using stored task dependencies and review buffers.
6. Link source-labelled notes and file references; preserve source locators, provenance, and revisions.
7. Review the tenant-isolation panel for unlinked or cross-customer records before progressing.
8. Open PointGuard to project the current milestone, next actions, blockers, and held effects.
9. Draft configuration changes and customer communications without sending or applying them externally.
10. Submit proposed decisions to Approvals and preserve the local decision receipt.
11. Run acceptance tests, mark only locally evidenced work complete, and leave unsupported effects held.

Scheduling records

• Milestone records
• Deadline and workback todo records
• Dependency records
• Owner assignment records
• Implementation milestone to-do records with dueAt, priority, completion state, tags, and revisions
• Workback dependency records linking tasks to a target deadline

Sources and evidence

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

• source_record:project:customer-implementation
• 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/notebook/projects/
• /app/notebook/to-dos/
• /app/notebook/agenda/
• /app/notebook/approvals/
• /app/notebook/files/
• /app/notebook/field-guides/
• /app/notebook/agent-logs/
• /app/pointguard/
• project:customer-implementation
• Observed native contract: records preserve canonical IDs, provenance, revisions, lifecycle, tags, links, attachments, and record revisions
• Observed native contract: PointGuard is a persistent cross-app context surface and specialist apps remain execution and canonical-record owners
• Observed native contract: provider, credential, database, customer, publication, and production effects are held