Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

project template / candidate

Field guide build — qualification

The distinct qualification record for Field guide build. This page is proposal-only.

Status: proposedLifecycle: candidate

Record status

Record ID
project:field-guide-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.

  • Submitting with a blank title, purpose, owner, audience, source reference, or authority boundary is rejected with an inline, field-associated error.
  • A source reference must identify an existing record or be marked unresolved; arbitrary unverified references cannot produce a qualified guide.
  • A due date without a time zone is rejected; invalid dates, impossible times, and dates earlier than the project start are rejected.
  • A dependency cycle is rejected and displays the records forming the cycle.
  • A task depending on an incomplete prerequisite cannot transition to complete; the blocked reason is required.
  • The guide cannot transition from proposed to qualified unless ordered steps, prerequisites, failure recovery, owner, source provenance, and next maintenance date are present.
  • Changing a source, step, owner, scope, or deadline creates a new revision, preserves the prior revision, and records the reason and editor.
  • A failed test keeps the project in proposed or held state and displays the failed test, expected result, observed result, and next action.
  • Keyboard-only completion reaches every field, control, validation message, dialog, and destructive-action confirmation in logical order.
  • Every form control has a visible label, programmatic name, instructions where needed, and an error message associated with the control.
  • Status, blocked state, overdue state, and approval state are not conveyed by color alone; text and accessible announcements are provided.
  • Reduced-motion settings do not remove essential schedule, validation, revision, or failure information.
  • Private, source-labelled, and held records are excluded from public search or publication proposals unless an explicit local approval permits the intended visibility.
  • File references expose type, size, provenance, and custody state; the form must not imply that upload or protected storage succeeded.
  • Delete, discard revision, unlink source, and reset actions require an explicit confirmation naming the affected record and consequence.
  • Destructive confirmations provide Cancel as the safe default, are keyboard accessible, and do not proceed on Escape, focus change, or duplicate submission.
  • An authority test fails any attempt to send messages, write to providers, publish content, alter customer records, create credentials, or claim production state.
  • An authority denial leaves the record, evidence, and user-entered form data intact and records a held receipt rather than reporting success.
  • If save, validation, scheduling, or revision persistence fails, the interface shows a plain-language failure state, preserves recoverable input locally where available, and offers retry without duplicate records.
  • If a linked record disappears or becomes inaccessible, the guide is marked held or blocked and identifies the missing link; it does not silently substitute another record.
  • A successful qualification receipt names the project ID, guide revision, tests passed, reviewers, remaining held effects, and next maintenance date.

Negative and held-state tests

  • A route or named native surface may be mistaken for a connected production feature.
  • Unverified or stale source material can make an operational guide unsafe or misleading.
  • Hidden dependency cycles or missing owners can create false readiness.
  • Ambiguous dates, time zones, or recurrence can cause missed reviews.
  • Revision overwrites can destroy provenance and invalidate prior qualification evidence.
  • Private notes, file metadata, or customer-like information may leak through search, links, exports, or public documentation.
  • Destructive actions may remove source links, revisions, or evidence without recovery.
  • Accessibility failures can prevent keyboard, screen-reader, low-vision, or reduced-motion users from qualifying the guide.
  • Agent or provider actions may be mistaken for completed external work.
  • Calculator or other instrument links may be irrelevant, stale, or unsupported by the guide's evidence.

Qualification claim boundary

Potentially allowed only after the stated evidence

  • This is a proposed project template for creating, testing, and maintaining a source-bound field guide.
  • The proposal defines form fields, workback rules, dependency handling, revision controls, accessibility checks, privacy boundaries, and held-effect tests.
  • The supplied native contract describes local or indexed Notebook surfaces and preserved record metadata.

Still held

  • No claim that a field-guide backend is deployed or connected.
  • No claim that provider, credential, database, customer, publication, or production effects are available.
  • No claim that any guide is complete, qualified, approved, published, or operational.
  • No claim that any external calendar, message, file upload, or protected Vault write succeeded.
  • No claim that source evidence is current, sufficient, or authoritative beyond the supplied record.
  • No claim that any instrument is required or connected for this project type.

Sources and evidence

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

  • source_record:project:field-guide-build
  • NotebookCollectionKind.project
  • NotebookTodoPayload.dueAt
  • Notebook Agenda deadlines/workbacks
  • project:field-guide-build:qualification
  • /app/notebook/field-guides/
  • /app/notebook/projects/
  • /app/notebook/to-dos/
  • /app/notebook/agenda/
  • /app/notebook/approvals/
  • /app/notebook/agent-logs/