Source: https://guthlabs.ai/docs/field-guides/macos-27/steps/ field guide / candidate # macOS 27 โ€” steps The distinct steps record for macOS 27. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: field-guide:macos-27 **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. Establish prerequisites: confirm Tim is the accountable owner; link the related jobs; record the source locator agents/index.html#tim; and create a source-labelled note with the source record, source SHA-256, canonical ID, provenance, revision, and lifecycle. Checkpoint: the scope names a discovery question rather than a deployment or product-support claim. - 2. Define the capability question in Notebook Projects and link this guide, the source note, and a qualification log. State the exact macOS surface under consideration and explicitly list effects that are out of scope, including provider, credential, database, customer, publication, and production effects. Failure branch: if the question requires an unobserved platform behavior, mark the proposal Held and request a new verified source instead of filling the gap by inference. - 3. Inventory only the observed native contract relevant to the question. The available contract establishes project and field-guide collections, deadline payloads, provenance-preserving records, PointGuard context, specialist-app execution ownership, and prototype or indexed GuthHub routes. Checkpoint: every capability statement is paired with a contract clause or source locator; unpaired statements are removed or marked unverified. - 4. Map each proposed activity to an observed local route. Use Field Guides to inspect this procedure, Notes for source-labelled observations, Files for local file references, To-dos and Agenda for deadlines and workbacks, Approvals for review state, Projects for grouping, Agent Logs for authority and receipts, and PointGuard for context. Failure branch: if a route appears to imply a connected web feature, record that the route is a local prototype or index and hold the external effect. - 5. Create an evidence ledger. For each observation, preserve the canonical ID, origin, source locator, source SHA-256, provenance, revision, lifecycle, tags, links, and any local attachment reference. Do not use an attachment as proof of production behavior. Checkpoint: another reviewer can trace each evidence item back to its source record or observed native contract. - 6. Draft a bounded Swift and SwiftUI implementation hypothesis as a proposal only. Separate interface questions, native capability questions, and canonical-record ownership. Treat specialist apps as execution and canonical-record owners and PointGuard as a persistent cross-app context surface, not as proof of a connected macOS feature. Failure branch: if ownership is ambiguous, create a Needs review approval and stop qualification. - 7. Add a deterministic workback: discovery due date, implementation-review due date, decision due date, next checkpoint, priority, and completion state. Use NotebookTodoPayload-compatible fields and preserve revisions. Checkpoint: no item is marked complete until its evidence and reviewer receipt exist; overdue items remain visible in Today, To-dos, or Agenda as local records. - 8. Submit the proposal through Approvals with status Needs review. The reviewer must inspect scope, evidence traceability, accessibility implications, ownership boundaries, held claims, and unresolved gaps. Failure branch: mark Held when evidence is missing, source integrity is unavailable, a route is treated as proof of connection, or a proposed effect crosses the web boundary. - 9. Record the decision receipt in Agent Logs and link it to the guide, project, evidence ledger, and approval. Allowed outcomes are Approved locally for further proposal work or Held for additional verified evidence. Neither outcome means deployment, provider connection, database authority, customer indexing, publication, or qualification in production. - 10. Close the guide only when all completion criteria pass. Otherwise retain lifecycle proposed or held, preserve the failure reason, assign a follow-up owner, and schedule the next checkpoint. ## Deadline and chronology rules - Set discovery, implementation-review, and decision due dates before work begins. - Use a next-checkpoint date whenever evidence is incomplete or a decision is Held. - Do not mark a task complete without a linked evidence record and review receipt. - If a source revision or SHA-256 changes, reopen the affected evidence and decision records. - Keep overdue and held work visible in local Today, To-dos, or Agenda views. - External calendar, provider, messaging, publication, and production writes remain held. ## Failure branches during execution - Treating the macOS 27 title or related job names as proof that a native capability exists. - Treating a named GuthHub route as a connected web feature or production implementation. - Claiming Swift, SwiftUI, App Intents, Spotlight, cross-device behavior, deployment, publication, or customer indexing without supplied evidence. - Confusing PointGuard's persistent context role with specialist-app execution or canonical-record ownership. - Using unsupported instruments, live providers, credentials, external writes, or hidden uploads. - Losing source provenance, source hash, revision history, or canonical record links. - Marking work complete without a reviewer receipt or while evidence is stale. - Creating inaccessible forms, unclear status states, or deadlines that cannot be inspected locally. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:field-guide:macos-27` - `agents/index.html#tim` - `source record field-guide:macos-27:plan` - `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/notebook/agent-logs/` - `App route /app/notebook/notes/` - `App route /app/notebook/files/` - `App route /app/notebook/projects/` - `App route /app/notebook/to-dos/` - `App route /app/notebook/agenda/` - `App route /app/notebook/approvals/` - `App route /app/pointguard/`