Source: https://guthlabs.ai/docs/project-templates/app-feature-build/qualification/ project template / candidate # App feature build โ€” qualification The distinct qualification 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**: qualification **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. ## Qualification status **Result**: NOT RUN **Disposition**: HELD **Reviewer**: Not recorded **Receipt**: Not recorded This page defines proposed acceptance criteria for the qualification lane. It does not execute tests, establish compliance, qualify the subject, or authorize an effect. ### Lane-specific instrument aids No verified instrument is assigned to this qualification lane. ## Outcome definitions **Verified**: All stated evidence and acceptance requirements passed for the exact reviewed revision; this still does not authorize deployment or an external effect. **Failed**: One or more deterministic acceptance requirements failed with an inspectable reason. **Needs review**: Evidence or interpretation is incomplete, conflicting, or awaits an identified human reviewer. **Held**: Authority, required evidence, safe execution conditions, or a principal gate is absent. The current record remains NOT RUN / HELD. These definitions describe candidate outcomes only. ## Proposed deterministic acceptance tests Route-resolution and distinct-content checks apply only to the admitted canonical routes in this record. Held source-proposed extensions are non-resolving proposals and are excluded. - Required-field test: submission is rejected when title, owner, scope boundary, source reference, target review date, or acceptance tests are missing; each error is attached to the relevant field and announced to assistive technology. - Type and range test: dates parse deterministically with timezone; dueAt rejects invalid dates, impossible local times, and disallowed past dates; numeric limits reject non-finite or out-of-range values. - Cross-field test: out-of-scope behavior cannot be listed as an acceptance criterion; a dependent task cannot precede its predecessor; a target review date cannot precede a required milestone. - Dependency test: when a required record, source locator, provider, credential, database, customer, publication, or production capability is unavailable, status becomes Blocked or Held with a visible reason and no simulated success. - Authority test: local draft or index actions may be staged only within the declared owner; external sends, writes, publication, credential use, customer changes, and production changes remain disabled or Held and produce an explicit receipt. - Revision test: editing a source-bound requirement creates a new revision, preserves the prior value and provenance, records actor and timestamp, and invalidates dependent approval until re-reviewed. - Accessibility test: every control has a programmatic label, required state, description, and error association; keyboard-only users can complete and review the form; focus moves to the first invalid field; status and failure messages are announced; no information relies on color alone. - Accessibility test: order of headings, labels, controls, errors, and review summaries is logical at narrow and zoomed layouts; contrast and focus indicators meet the designated product accessibility threshold, with unresolved findings marked Held. - Privacy test: fields are classified as public, private, or held before entry; private or sensitive values are excluded from public routes and search results; attachments show type, size, local custody, and visibility without hidden upload. - Privacy failure test: an attempt to place private content in a public claim or public Site context is rejected with a corrective message and an audit receipt. - Destructive-action test: delete, discard, overwrite, revoke, or replace actions identify the exact record and consequences, require deliberate confirmation, offer cancel, and preserve a reversible revision or recovery path where supported. - Destructive-action test: cancel, Escape, browser back, refresh, and duplicate submission do not commit a destructive action or create duplicate records. - Failure-state test: validation failure preserves entered values; dependency failure preserves the draft; scheduling conflict leaves the original schedule unchanged; provider or storage failure reports Held or Unavailable rather than success. - Failure-state test: network or local persistence interruption produces a retry path that is safe to repeat and identifies whether the last operation was committed, uncommitted, or unknown. - Review test: the project cannot move to an approval-ready state until required tests, evidence links, unresolved hazards, authority boundaries, and revision status are present. - No-claim test: all proposal screens and receipts state that the feature is not qualified, deployed, provider-connected, database-backed, customer-indexed, published, or production-active unless separately verified. ## Negative and held-state tests - A prototype route may be mistaken for a connected implementation. - Missing or ambiguous source provenance may cause unsupported requirements. - Silent deadline shifts can invalidate dependent work and review commitments. - Provider, credential, database, customer, publication, or production effects may be falsely represented as complete. - Private source material may leak into public routes, search, messages, attachments, or claims. - Destructive edits may remove canonical records or revision history. - Inaccessible validation and focus behavior may prevent completion or conceal errors. - Duplicate retries may create duplicate records or conflicting revisions. - Unresolved conflicts or blocked dependencies may be mistaken for qualification. ## Qualification claim boundary ### Potentially allowed only after the stated evidence - A proposal template exists for source-bound app feature qualification. - The project defines fields, validation, workback, dependency review, accessibility, privacy, revision, authority, and failure-state tests. - The current route references are local prototype or indexed surfaces as stated by the observed contract. - External effects are explicitly held pending verification. ### Still held - The feature is qualified, shipped, deployed, or production-ready. - A provider, credential, database, customer record, publication surface, or production backend is connected. - A task, schedule change, message, approval, upload, or external write has executed outside the local prototype boundary. - The project is complete, accepted, or backed by live operating data. - The capability is available to customers or indexed publicly. ## 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` - `Notebook records provenance and revision contract` - `PointGuard persistent cross-app context surface` - `Current GuthHub app routes and held web boundary`