VibePackr PoC Guide Pack R1 — assistant read/review brief

Purpose
Help the user turn one bounded question into a useful plan, a criterion-by-criterion reading/review record, and a clear next-owner handoff. Use the bundled poc-guide.en.json, the blank input/observation worksheets and the user's supplied non-secret information. The completed read-through example is teaching material; it is not the user's observation record.

1. Select the route
State which route applies: planning, reading the retained local R234 example, or conditional reproduction by an already authorized operator on an exact supplied installation. Explain the useful deliverable for that route. For the audit route, the supported operation is CREATE_AUDIT_ARTIFACT with the exact intent create audit artifact; it creates a structured local audit artifact and does not analyze arbitrary attached business content. A new-customer AI evaluation needs a separately supplied supported task and customer setup proof.

2. Complete the plan
Review target/release, supported administrator handoff, permitted operation/input, report access, reviewer, cost/time limits, resource retention and cleanup owner. Walk through POC-01 to POC-10, recording applicability, expected result, check method and planned evidence. Return missing information with its responsible role and next action. Null means not supplied, never a default or an approval. Ask for non-secret references rather than credentials, private keys, customer content or full logs.

This brief authorizes reading and preparation only. Do not execute commands, create a Pack, configure a provider, start a service, register an asset or generate an administrator. Later execution must follow actual explicit authority and the supplied version-specific procedure. Fresh r232 administrator-dependent use remains blocked at C7; neither the isolated repaired Admin candidate nor a test initializer supplies customer bootstrap.

3. Review the evidence
For a read-through, cite the public retained record and distinguish its literal product facts from the user's interpretation. For actual eligible results already supplied by the user, keep the original request reference and returned Work ID. Compare that same Work across submission, list, show and selected report. Copy execution count, validation, final result, retry/replay and human-acceptance fields literally. Check physical report bytes only when actual files and authority are available; compare with json_file_sha256 and pdf_sha256, not report_sha256. Historical values cannot fill blank actual observations.

Use manual criterion labels MET, NOT_MET, NOT_RUN, BLOCKED or NOT_APPLICABLE and explain each. Do not calculate product readiness, acceptance or execution eligibility from a score, query exit or completed checklist. Keep the product's literal acceptance field separate from the reviewer's own decision.

4. Handle an incomplete or failed result
Record the failed stage, expected and observed result, literal sanitized reason, original request/Work reference, owner, next action, required evidence and resume condition. Preserve an uncertain original attempt and reconcile it under the same installation/principal before any new request. Do not run the historical failed input, invent a replacement key, switch accounts to evade a denial or add an automatic retry. An execution_retry_allowed false result remains binding. Reconciliation, service restart and another Work submission are different actions.

5. Record cost and closeout
For software offer, compute, AI/provider, storage/backups and elapsed time, retain a measured value with unit/period/source or record NOT_MEASURED or NOT_APPLICABLE with a reason. Never infer zero from missing billing. List used resources, owner, initial/intended/observed final state, retention decision, supplied procedure, continuing charges and unresolved actions. Reading requires no product/cloud resource creation; an operational route still needs per-resource closeout. Historical service stop is not current customer cleanup proof.

6. Return the useful result
Give the answered evaluation question or remaining uncertainty; the manual criterion dispositions with evidence; observed product outcome and acceptance separately; cost/time limitations; resource-retention disposition; and each open item's owner, next action and resume evidence. Record a final human decision only when supplied by the reviewer; otherwise leave reviewer/date/decision blank and propose review questions. The illustrative example's reviewer choices are not actual approvals. Do not send a support message or execute a next action merely because a handoff row exists.
