App feature build — deadlines

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

1. Create a local Project record with canonical ID, origin, provenance, revision, lifecycle, and ownership.
2. Enter only source-supported requirements and attach source locators and SHA-256 values where available.
3. Define the proposed browser components, canonical record owner, persistence boundary, and held external effects.
4. Add milestones and work items with explicit due dates, priorities, dependencies, and completion states.
5. Generate a deterministic workback from the target review date; flag missing dates, circular dependencies, and overdue items.
6. Link notes, file references, approvals, and agent logs without copying records into hidden automation.
7. Configure a PointGuard projection showing the current objective, next action, blockers, deadline summary, and links back to canonical Notebook records.
8. Run local validation and accessibility checks, then create a review proposal and receipt.
9. 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/