Website surface — qualification

Record status

Record ID

project:website-surface

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.

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.

• A submission with a blank title, slug, purpose, owner, or approver is rejected with field-level errors.
• A slug must be lowercase, non-empty, and contain only letters, numbers, and hyphens; duplicate slugs are rejected within the project scope.
• A route entry must contain a valid path, page purpose, visibility, and crawl intent; duplicate routes are rejected.
• A public claim cannot be marked allowed unless it has a source reference, provenance note, reviewer, and review status of approved; otherwise it remains Held.
• A source-labelled claim change creates a revision record and preserves the prior claim, source locator, and disposition.
• A task with a dueAt value lacking a time zone, invalid date, or dependency to a missing record is rejected.
• A release proposal is blocked when any required gate is incomplete, any critical finding is unresolved, or any approval is Held or missing.
• A crawl review must report every in-scope route as reachable, intentionally excluded with rationale, or failed; unknown status blocks release qualification.
• Accessibility review must include keyboard operation, visible focus, semantic headings/landmarks, form labels and errors, text alternatives, contrast evidence, zoom/reflow, and reduced-motion behavior where relevant.
• Contrast failures must identify the affected component, measured values, threshold rationale, remediation owner, and retest result.
• Forms must expose labels, required state, input purpose, format guidance, inline errors, summary errors, and a non-destructive recovery path.
• Privacy review must identify every collected field, purpose, visibility, retention proposal, deletion/access proposal, and authority status; unspecified fields block qualification.
• Destructive actions must require an explicit confirmation naming the target and consequence, provide cancel, and preserve a receipt; cancellation must leave the record unchanged.
• Approval controls must distinguish Needs review, Approved, and Held; approval must not imply publication or external effect.
• On save, route, crawl, instrument, or evidence failure, the interface must show a specific error, preserve unsaved input where possible, avoid duplicate records, and provide retry or recovery guidance.
• A failed dependency, unavailable provider, missing credential, held database, or held publication path must produce a visible held state rather than a success claim.
• Search and visibility tests must confirm private or held records are not presented as public customer-indexed content.
• A final qualification record must include owner, revision, evidence links, open hazards, decision status, deadline state, and explicit held effects.

Negative and held-state tests

• Unsupported, stale, or ambiguous claims could be presented as public facts.
• A native route or named surface could be mistaken for a connected web feature or production release.
• Provider, credential, database, customer, publication, and external calendar effects may be incorrectly implied.
• Missing source locators, hashes, provenance, or revisions can make claims impossible to audit.
• Crawl failures, duplicate canonical URLs, orphan routes, or accidental indexing could create an uncontrolled public surface.
• Inaccessible keyboard flows, unlabeled fields, weak contrast, missing alternatives, or non-announced errors could exclude users.
• Collecting unnecessary personal or customer data could exceed the proposed authority and privacy boundary.
• Destructive edits or deletion could occur without target confirmation, cancellation, or revision recovery.
• Unresolved dependencies, timezone errors, and silent deadline changes could cause missed release gates.
• Partial saves, duplicate submissions, stale revisions, and provider failures could create contradictory records.
• Medical, financial, legal, safety, or other high-consequence claims may require specialist review not established by this project record.

Qualification claim boundary

Potentially allowed only after the stated evidence

• The project is a proposed qualification template for a website surface.
• The observed Guth contract includes local prototype or index routes for Notebook, Agenda, Approvals, Projects, Notes, Files, To-dos, Search, and related surfaces.
• The verified instrument directory includes wcag-contrast-ratio-checker as a verified-clean instrument.
• Qualification criteria, deadlines, dependencies, revisions, and approval states can be proposed as records and tests.

Still held

• That any website has been built, deployed, published, crawled, indexed, or qualified.
• That any provider, credential, database, customer system, calendar, storage, or publication channel is connected.
• That any route represents a production web feature or external write.
• That a claim is true merely because it appears in a proposed claim register.
• That accessibility, privacy, security, crawl, or release compliance has been achieved without recorded evidence and approval.
• That the listed contrast checker alone establishes full accessibility conformance.
• That a proposed approval means external release or customer availability.

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• source_record:project:website-surface
• 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; specialist apps remain execution and canonical-record owners
• Observed native contract: current GuthHub app routes are local prototypes or indexes and provider, credential, database, customer, publication, and production effects are held
• ALLOWED_INSTRUMENTS: wcag-contrast-ratio-checker (VERIFIED_CLEAN)