Liquid Glass — steps

Record status

Record ID

field-guide:liquid-glass

Parent lifecycle

candidate

Page lane

plan

Lane lifecycle

proposed

Owner

Tim

Owner role

Not separately recorded

Owner status

Not separately recorded

Qualification result

NOT RUN · held for evidence and human review

Working browser surface: Field guides — documentation — Inspect the guide and persist local checkpoints. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held.

Ordered procedure

1. Read the source record and record its exact ID, owner agent, related jobs, and source reference in a source-labelled note.
2. State the objective as a proposal to investigate Liquid Glass; explicitly mark implementation, provider connection, production behavior, publication, and qualification as unverified or held.
3. Define one bounded capability hypothesis connected to one or more listed related jobs. Do not add platform behavior not present in the source record or observed contract.
4. Identify the likely specialist execution and canonical-record owner. Use PointGuard only as a persistent context surface, not as proof of execution ownership.
5. Create a short observation plan covering platform discovery, Swift and SwiftUI implementation questions, App Intents and Spotlight questions, cross-device implications, and native capability qualification.
6. Create dated Notebook to-dos with owners, priorities, dependencies, and review signals. Use dueAt for every externally meaningful checkpoint; if no date is supplied, mark the date as required rather than inventing one.
7. Collect only source-labelled observations and local artifact references. Record device, OS or SDK labels only when actually observed; otherwise leave them unknown.
8. For each observation, capture expected result, observed result, reproduction steps, source locator, and an evidence reference. Separate facts, proposals, and unresolved questions.
9. Check accessibility of any proposed visual surface, including readable contrast, keyboard or focus behavior where applicable, motion or translucency concerns, and non-visual equivalents. Do not infer support from a named route.
10. Review App Intents and Spotlight ideas as proposals only. Record the intended intent or indexed content, ownership, visibility boundary, and the condition that would be required before any external indexing claim could be made.
11. Review cross-device behavior as a proposal. Record device classes, shared context assumptions, synchronization questions, and failure handling without asserting continuity or synchronization.
12. Run the qualification checkpoint: confirm that evidence is reproducible, records preserve provenance and revisions, ownership is explicit, and all held effects remain held.
13. Submit the qualification decision for human approval as Needs review, Approved, or Held. Preserve the decision rationale and supporting evidence IDs.
14. If approved for a bounded prototype, create a separate project or implementation work record with linked evidence; do not convert this guide into a deployment or publication claim.
15. Close the guide only when completion criteria are met and an agent-log receipt records the work, authority boundary, evidence, unresolved risks, and next review date.

Deadline and chronology rules

• Every qualification task must have a concrete dueAt before it is considered scheduled.
• Create an initial scope checkpoint before collecting implementation evidence.
• Create an evidence checkpoint after each bounded investigation area.
• Create an accessibility checkpoint before any prototype recommendation.
• Create a human-review deadline for the qualification decision.
• If a dependency is missing, mark the task blocked and record the missing record or evidence instead of advancing the due date silently.
• If a deadline passes without evidence, move the related task to Held or Needs review and preserve the reason.
• Do not infer deadlines from the source record; require a human-supplied date when none is provided.

Failure branches during execution

• A named Liquid Glass guide may be mistaken for an implemented Apple-native capability.
• Swift, SwiftUI, App Intents, Spotlight, or cross-device behavior may be assumed from related-job labels without evidence.
• A route labeled indexed or prototype does not prove a connected web feature or canonical backend.
• PointGuard may be mistaken for the execution or canonical-record owner.
• Translucency, motion, contrast, focus, and legibility risks may be missed if visual review is treated as sufficient.
• App Intents or Spotlight language may accidentally imply customer indexing or external publication.
• Cross-device language may accidentally imply synchronization, continuity, or provider connection.
• Missing due dates can create invisible work or false completion; dates must be supplied or the task held.
• Local file references may be mistaken for uploaded or protected assets.
• Educational contrast calculations must not be presented as platform qualification or accessibility conformance certification.
• Erroneous or incomplete observations may be carried forward unless source locators, revisions, and confidence are preserved.

Sources and evidence

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

• source_record:field-guide:liquid-glass
• agents/index.html#tim
• field-guide:liquid-glass
• Observed native contract: project_and_field_guide_collections
• Observed native contract: deadlines
• Observed native contract: records
• Observed native contract: pointguard
• App route: /app/notebook/field-guides/
• App route: /app/pointguard/
• App route: /app/notebook/notes/
• App route: /app/notebook/files/
• App route: /app/notebook/to-dos/
• App route: /app/notebook/approvals/
• App route: /app/notebook/agent-logs/
• Allowed instrument directory: wcag-contrast-ratio-checker