Source: https://guthlabs.ai/docs/project-templates/app-feature-build/forms/ project template / candidate # App feature build โ€” forms The distinct forms 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**: forms **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. ## Proposed form sections Each section is a candidate schema for inspectable records. Required-field presence does not establish factual truth. ### Intake Identify the capability, source, intended users, and reason for the work before scope is accepted. - project title - capability name - problem statement - desired user outcome - requestor - product owner - feature owner - target app or surface - audience - source record IDs - source locators - source SHA-256 when available - provenance note - requested start date - requested target date - priority - success signal - known constraints - intake status ### Scope and boundaries Define what the project will and will not produce, including held effects and unsupported assumptions. - in-scope outcomes - out-of-scope outcomes - required user flows - supported record types - visibility classification - canonical-record owner - execution surface - external effects held - provider or credential dependency status - database or customer authority status - publication status - acceptance owner - scope approval status ### Owners and responsibilities Assign accountable people or roles for each decision and deliverable. - project owner - delivery owner - requirements owner - design owner - implementation owner - evidence owner - accessibility reviewer - risk owner - approval owner - closure owner - backup owner - responsibility notes ### Milestones and deliverables Break the capability into reviewable outcomes with explicit exit conditions. - milestone ID - milestone title - deliverable - owner - planned start - planned finish - due date - priority - status - preceding milestone IDs - required inputs - exit criteria - evidence required - approval required - completion state - revision note ### Deadlines and workback Create a deterministic schedule from the target date and expose conflicts before work begins. - target date - target date type - timezone - hard or soft deadline - workback start date - buffer days - review window - accessibility review date - approval date - evidence freeze date - handoff date - dependent due items - recurrence candidate - conflict flag - schedule rationale - schedule revision history ### Dependencies and blockers Track prerequisites owned by this project or another surface and define failure handling. - dependency ID - dependency type - description - blocking milestone - owner - source or linked record - needed by date - status - verification method - fallback plan - escalation owner - blocked reason - resolved date - resolution evidence ### Tools, guides, and execution surfaces Declare which native surfaces are proposed for each task without implying connection or production behavior. - tool or surface name - kind - route - planned use - canonical owner - execution owner - input records - output records - authority boundary - failure state - human review point - status ### Evidence and receipts Preserve inspectable support for requirements, decisions, testing, and completion. - evidence ID - evidence type - claim supported - linked milestone - record or file reference - source locator - source SHA-256 when available - captured by - captured at - provenance - revision - visibility - review status - missing evidence note ### Approvals and decisions Record human review for scope, design, readiness, and closure. - approval ID - decision area - proposal summary - decision owner - reviewers - submitted at - decision status - conditions - rejection reason - held reason - receipt reference - decision revision - next review date ### Risks and failure states Make material uncertainty, safety, privacy, accessibility, and delivery risks actionable. - risk ID - risk statement - category - likelihood - impact - severity - trigger - owner - mitigation - contingency - due date - status - residual risk - escalation path - risk evidence ### Closure and handoff Confirm what was completed, what remains held, and what evidence supports the final state. - closure status - delivered outcomes - undelivered outcomes - open risks - open dependencies - accepted deviations - final evidence references - approval reference - handoff owner - handoff record IDs - follow-up due date - retention or archive note - closure summary - closed by - closed at ### Accessible state contract - Every field requires a visible and programmatic label. - Required and optional fields must be stated in text. - Invalid entries require an actionable message linked to the field. - Blocked and Held states remain visible without relying on color alone. ## Supporting documentation fields These fields come from the app_features lane and remain separate from the primary operating form. ### Feature identity Define the capability and its ownership without claiming implementation state. - Feature title - Short purpose - Project owner - Notebook project ID - Requested lifecycle - Audience - Tags ### Source-bound requirements Capture what is supported by supplied records and distinguish unknowns. - Requirement statement - Source record ID - Source locator - Source SHA-256 - Requirement type - Acceptance evidence - Open question - Confidence ### Scope and boundaries Make the proposed browser behavior explicit and prevent unsupported external effects. - In-scope components - Out-of-scope behavior - Canonical record owner - Local persistence scope - Provider effects held - Credential effects held - Database effects held - Publication effects held ### Deadlines and workback Plan ordered work from a target review date using explicit due dates. - Target review date - Milestone name - Milestone owner - Due date - Priority - Dependency IDs - Estimated effort - Completion state - Recurrence candidate - Risk or blocker ### Links and PointGuard Connect supporting local records and define the compact current-work projection. - Linked note IDs - Linked file-reference IDs - Linked to-do IDs - Linked approval ID - PointGuard room label - Current objective - Next action - Projection visibility ### Review and handoff Record human review state and preserve a receipt for each proposed decision. - Reviewer - Review status - Review notes - Approval date - Held effects checklist - Decision receipt - Revision note ## Required or proposed record references No record existence is asserted by this documentation page. - project record - source-bound requirement notes - milestone to-dos - deadline and workback items - dependency records - evidence records or file references - approval record - risk records - closure note - Project record owned by Notebook Projects - Source-bound requirement records with source locators and SHA-256 provenance - Feature work items using NotebookTodoPayload fields - Deadline and workback records - Linked notes and file references - Local approval record - PointGuard projection record - Agent log and receipt 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/`