Source: https://guthlabs.ai/docs/project-templates/native-release/forms/ project template / candidate # Native release โ€” forms The distinct forms record for Native release. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:native-release **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 Establish why the release preparation exists and who owns the decision. - project title - release target or build identifier - requestor - project owner - release reviewer - requested start date - target decision date - business or user purpose - source record links - current lifecycle - intake notes ### Scope and success criteria Define what is included, excluded, and acceptable for review. - in-scope app surfaces - out-of-scope surfaces - supported platform or device assumptions - required packaging outputs - required review checks - success criteria - non-goals - known limitations - change-control rule ### Milestones Break preparation into ordered, reviewable outcomes. - milestone name - milestone owner - description - planned start - planned finish - status - entry criteria - exit criteria - evidence required - linked dependencies - linked to-dos ### Deadlines and workback Record decision deadlines and derive actionable preparation dates without implying external scheduling writes. - decision deadline - deadline type - timezone - hard or soft deadline - workback anchor - workback offsets - derived task due dates - buffer days - conflict notes - human confirmation state ### Dependencies and owners Make blocking relationships and accountability explicit. - dependency description - dependency type - blocking milestone - dependency owner - needed by date - status - confirmation source - fallback plan - escalation owner ### Tools and guides Identify the designated local surfaces and procedures for each step. - tool or guide name - kind - linked route or record - intended use - owner - required before step - authority boundary - availability state ### Evidence and receipts Capture source-labelled proof of review work while preserving provenance and revision history. - evidence title - evidence type - related milestone - captured by - captured at - source locator - source SHA-256 if available - record revision - attachment or file reference - observed result - limitations - review status ### Approvals Separate local proposal decisions from any external release action. - approval request - decision owner - decision deadline - decision options - supporting evidence - status: Needs review, Approved, or Held - decision note - receipt reference - follow-up action - approval timestamp ### Risks and failure states Expose conditions that could block, invalidate, or delay review. - risk statement - category - likelihood - impact - severity - trigger - mitigation - contingency - risk owner - review date - status - unresolved consequence ### Closure Confirm whether preparation is complete, deferred, or stopped and preserve remaining work. - closure status - completion date - final decision - completed milestones - open items - unresolved risks - evidence completeness check - approval completeness check - handoff owner - lessons or notes - held external effects - closure reviewer ### 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. ### Release identity Define the proposed release without implying an active Apple or production connection. - Project name - App name - Internal release label - Owner - Release type - Target decision date - Current lifecycle - Description - Tags ### Scope and evidence Record what is included and how a reviewer can inspect it. - Build identifier or local reference - Included changes - Excluded changes - Supported devices or platforms - Known limitations - Test evidence links - Accessibility review status - Open questions ### Workback and deadlines Create explicit local milestones from the human-selected decision date. - Decision date - Milestone name - Milestone owner - Due date and time - Priority - Dependency links - Recurrence candidate - Completion state - Review required - Blocked reason ### Human review and release decision Separate preparation from approval and external release effects. - Reviewer - Review checklist - Decision status - Decision rationale - Receipt or evidence links - Held external effects - Follow-up due date ## Required or proposed record references No record existence is asserted by this documentation page. - project record - scope record - milestone records - deadline and workback to-dos - dependency records - owner assignments - tool and guide references - evidence records - approval records - risk records - closure record - Project record with canonical ID, lifecycle, origin, provenance, revision, tags, links, and attachments - Release milestone to-dos with dueAt, priority, completion state, tags, revisions, and deadline view - Source-labelled file references for build notes, test evidence, screenshots, and review documents - Approval records for each proposed release decision - Agent log records for any bounded assistance and receipts ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:native-release` - `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/files/` - `/app/notebook/approvals/` - `/app/notebook/paper/` - `/app/notebook/agent-logs/` - `Notebook records provenance, revisions, links, and attachments` - `PointGuard persistent cross-app context surface` - `Web boundary: provider, credential, database, customer, publication, and production effects are held` - `/app/pointguard/`