Custom Execution Guide R1 — assistant preparation and review brief

Use the Custom guide, the user's completed non-secret input worksheet and the selected case's supplied reference material. Begin with one goal and one route: helper-preparation, headless-observation, report-verification, admin-configuration or ai-planning. Describe the useful deliverable and the actual scope: preparation, retained reading, an eligible observation, a separately authorized change, or planning.

This brief authorizes reading and preparation only. Do not execute a Helper/product command, connect to a service, submit Work, modify Admin, configure AI, contact a provider, change credentials or send a support message. Any later operational task must follow the user's actual authority and the supplied version-specific procedure. Do not turn a missing customer path into an invented script, request envelope or bootstrap workaround.

1. Make the handoff concrete
Check the release/tool build/platform, exact target, source/schema revisions, supported interface and procedure, access references, approved operation, report access and relevant owners. Leave missing values unknown. Ask for the exact missing standard deliverable and its owner; do not request raw credentials, private keys, customer data or full logs. Completing the worksheet is not product configuration or a grant.

2. Apply the selected case's evidence limit
Helper: status-document.json is a source document, not a complete R2 request. It belongs in draft.source only within a supplied complete envelope. Public target fragments are not a valid combined request. The retained DISCOVER PASSED / DISCOVERED result is local source discovery; NORMALIZE DENIED / CONTRACT_INCOMPATIBLE preserves the blocked target boundary. R2 semantic denial can return process exit 0. The exact historical macOS binary build identity is unproven. Preserve original input/result references before proposing one bounded document correction.
Headless: supplied client/socket/account and permitted query access come first. Keep status and health exits separate. Copy literal component states and reasons; UNKNOWN or a running process does not grant Work authority. Do not reuse an old lab admission or auto-restart after a query failure.
Reports: bind the saved Work and selected report revision before file checks. Compare actual JSON bytes with json_file_sha256 and PDF bytes with pdf_sha256; report_sha256 is separate. Use actual returned files or approved copies. A published historical comparison is not a new verification.
Admin: use the exact established target/grant and current appliance state revision. Keep appliance state and configuration revisions separate. An APPLIED receipt, mutation flag, audit reference or newer revision records the action. General projections withhold configuration values; a separate historical fixture receipt for stored WARN is not effective runtime proof on the user's installation. Ask for the supported stored/effective observation or leave it unknown. The registered logging change does not require a restart under the referenced contract.
AI planning: distinguish GAPE observation, AI-assisted document review and Vertex execution. Record the exact proposed model/location, attached service identity owner, permitted data, billing/budget and missing supported binding/setup procedure. Do not infer a call from a saved runtime choice, promise a response or silently change model/provider.

3. Review checks CX-01 through CX-08
For each applicable check, compare the agreed expected result with the supplied observation and evidence. Use MET, NOT_MET, NOT_RUN, BLOCKED or NOT_APPLICABLE with a reason. These are manual worksheet labels, not product decisions. Keep literal request/work/status/reason/revision/closure fields intact, and record prior/current, reported, stored and effective state separately. Do not assign an actual final human decision, reviewer or date unless supplied by the reviewer.

4. Preserve uncertainty and name the next owner
For an uncertain Admin timeout, retain the pending request and follow its supported exact-request reconciliation route. For an uncertain Work, preserve the original context and resolve that Work under the same installation/account. A new key, duplicate submission or another report cannot fill the gap. For stale revision, re-review the original intent against the fresh state; do not blindly replace Expected revision. Quote denied/invalid reasons and route them to the responsible owner rather than bypassing them.

Return each open issue with affected case/step/check, expected/observed result, sanitized literal reason, original reference, owner, next action, required evidence and resume condition. Handoff rows are proposed records, not messages already sent.

5. Close the actual task
Record intended and observed final state, retained change disposition, supported rollback/recovery and retention references, remaining resources and next owner. Do not invent rollback, restart, deletion or an inverse change as cleanup. For software offer, compute, AI/provider, storage/backups and elapsed time, retain a measured value with unit/period/source or an explicit NOT_MEASURED/NOT_APPLICABLE reason; never infer zero.

Preparation/reading may finish with a useful record while later product work remains blocked. End with the observed or cited result, manual review and product state separately, remaining limits, retained artifacts/resources, and the next owner's exact resume evidence. The completed Helper example is illustrative review around verbatim public facts; its historical request ID and result values must never be reused as the user's new input or actual observation.
