Source: https://guthlabs.ai/docs/project-templates/app-feature-build/deadlines/ project template / candidate # App feature build โ€” deadlines The distinct deadlines record for App feature build. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:app-feature-build **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 date is required before a workback can be generated; if absent, status remains Needs review. - Every milestone must have an owner, due date, deliverable, and exit criteria. - Workback dates must include explicit review, accessibility, approval, evidence-freeze, and buffer entries where applicable. - A dependency due date must be no later than the first milestone that requires it. - Conflicting or overdue items must be flagged for human review; no external calendar write is implied. - Changing the target date creates a revision and recalculates proposed workback items without silently changing completed records. - Hard deadlines require an identified approval owner and escalation path. - A project cannot close while a blocking dependency, rejected approval, missing required evidence, or unresolved high-severity risk remains. - Completion state means recorded local project state only; it does not prove deployment, publication, provider connection, customer indexing, or production readiness. - Target review date is required before workback generation. - Every milestone must have a due date, owner, completion state, and priority. - A milestone due date cannot be later than the target review date unless explicitly marked post-review. - Dependencies must reference existing local work items; circular dependencies must block workback confirmation. - Use calendar dates and explicit timezone labels; do not infer provider calendars. - Overdue items are visibly flagged but are not automatically rescheduled. - Changing a target date creates a new revision and requires workback review. - Recurrence candidates are stored as proposals only and do not create scheduled external events. ## Workback sequence - Create a local Project record with canonical ID, origin, provenance, revision, lifecycle, and ownership. - Enter only source-supported requirements and attach source locators and SHA-256 values where available. - Define the proposed browser components, canonical record owner, persistence boundary, and held external effects. - Add milestones and work items with explicit due dates, priorities, dependencies, and completion states. - Generate a deterministic workback from the target review date; flag missing dates, circular dependencies, and overdue items. - Link notes, file references, approvals, and agent logs without copying records into hidden automation. - Configure a PointGuard projection showing the current objective, next action, blockers, deadline summary, and links back to canonical Notebook records. - Run local validation and accessibility checks, then create a review proposal and receipt. - Allow a reviewer to mark the proposal Approved or Held locally; do not send, publish, deploy, connect providers, or alter external systems. ## Scheduling records - milestone to-dos - deadline and workback items - dependency records - Deadline and workback records ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:app-feature-build` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `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` - `App route: /app/notebook/projects/` - `App route: /app/notebook/to-dos/` - `App route: /app/notebook/agenda/` - `App route: /app/notebook/files/` - `App route: /app/notebook/approvals/` - `App route: /app/notebook/notes/` - `App route: /app/notebook/field-guides/` - `App route: /app/pointguard/` - `project:app-feature-build` - `Notebook records provenance, revisions, 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/approvals/` - `APP_ROUTES:/app/pointguard/` - `APP_ROUTES:/app/notebook/agent-logs/`