VibePackr
GUIDE / 01 · POC Documentation

PoC Guide Pack: plan, follow one Work, review the result

Start with a useful plan and a real recorded example. Reproduce one supported local audit operation only on an already authorized, matching installation; keep customer setup gaps explicit.

Local review draft · Recorded R234 example · Fresh r232 customer path blocked at initial administrator setup

Start the guideGet the worksheets

Choose your route

You can study the recorded result without a live installation. Reproduction is a separate operator activity with its own prerequisites.

Prepare and review

Use the worksheet, recorded example and owner handoff without executing the product.

A plan is not installed or authorized product state.

Read the recorded local R234 run

Follow selected actual fields through one audit Work and JSON/PDF review.

Historical local candidate evidence, not a live session or r232/customer/production validation.

Reproduce only on an eligible existing installation

Use the exact command references after its operator verifies matching release, authority and prerequisites.

Not an install/bootstrap recipe; new r232 C7 and unresolved readiness stop dependent work.

Collect the operating handoff

InputOwnerWhat to confirm
Exact delivery version and supported installation routeDelivery contactMatches target; new r232 first-admin C7 remains unresolved
One permitted operation and acceptance criteriaPoC owner and product administratorWritten scope and operation permission; no health-only inference
Client, service, account and endpointAppliance operatorMatching local client/service and supplied socket; no invented startup
Non-secret input and retention choicesData ownerApproved input and private report handling
AI model, identity, network and cost if neededCloud/AI ownerSupported customer procedure and actual work validation; not proven by local audit
Report access and human reviewService operator and named reviewerReadable authorized artifacts and explicit review responsibility

Record references, not passwords or raw credentials. A filled worksheet does not establish product authority.

Actual retained record · local R234

See one Work before planning your own

The recorded exercise produced one Work with validation PASSED and human acceptance still pending. It also includes the original input error and its reconciliation. These are historical observations; reading them makes no service request.

New-customer r232 deployment, Vertex AI setup and customer storage connections remain separate checks. This recorded audit operation does not prove a provider call or its cost.

STEP 01

Choose one question worth answering

planning

Agree what the evaluation will teach you before spending or submitting.

Bring

  • Named PoC owner and reviewer
  • Non-confidential sample and intended use

Follow the sequence

  1. Choose either reading the retained audit example or, if already eligible, reproducing the supported audit operation. CREATE_AUDIT_ARTIFACT creates a structured local audit artifact; it does not audit arbitrary attached documents.
  2. Write acceptance criteria, budget, permitted actions and stop conditions. Separate a desired AI use case from this local audit example.
  3. Assign cloud, AI, data, product access and service-operation responsibilities. One person may fill several responsibilities; each requires its own access.

Check the result

  • A bounded evaluation question with accountable owners; no product action has occurred.

If it does not match

  • Unclear authority, cost owner or sensitive input: resolve with the PoC/data owner before operational work.

Keep for the handoff

  • Planning worksheet and unresolved dependencies
STEP 02

Choose the route your evidence supports

planning

Avoid treating a recorded example as a customer installation procedure.

Bring

  • Delivery version and environment, or an explicit unknown

Follow the sequence

  1. New r232 customer: prepare the plan and request the matching Marketplace/deployment/first-administrator procedures. Stop administrator-dependent use at C7.
  2. Existing authorized installation: obtain the handoff in step 4 and confirm the operation is supported for its exact release.
  3. Read the retained local R234 example now even if operational prerequisites are missing. No account, endpoint or provider is needed to read it.

Check the result

  • A recorded route choice: planning, retained-run reading, or conditional existing-operator reproduction.

If it does not match

  • Do not infer product authority from SSH, Cloud IAM, OS root, purchase or a running VM.

Keep for the handoff

  • Chosen route, release, missing procedure and responsible contact
STEP 03

Read one actual Work before trying your own

retained run

Recognize the action, outcome and limits of the retained example.

Bring

  • Bundled Headless guide and six-step recorded-run reader

Follow the sequence

  1. Open headless-worked-run-en.html; then read the tutorial sections of the Headless reference. This is selected actual output, not a live terminal.
  2. Follow the successful wording create audit artifact through submission, list, show, report and file checks. Read the earlier rejected wording only as history; do not execute it as a test.
  3. Notice the health exit 1/UNKNOWN observations and separately approved admission in that specific lab. That history is not permission to ignore your own missing readiness requirement.

Check the result

  • The recorded report has execution_count 1, validation_results PASSED, final_result AUTOMATION_COMPLETED_HUMAN_ACCEPTANCE_PENDING and closure.human_acceptance null.
  • The service was stopped after collection. Conversational approval did not change the product’s observed AWAITING_HUMAN_ACCEPTANCE state.

If it does not match

  • Do not copy the recorded Work ID, endpoint or digests into a new execution.
  • This R234 local record is neither r232 customer proof nor a production AI result.

Keep for the handoff

  • Notes separating observed result, pending human acceptance and applicability to your installation
STEP 04

Obtain an operating handoff

conditional existing operator

Make an eligible reproduction concrete without inventing setup commands.

Bring

  • Matching installed client/service release
  • Authorized local account and private writable working directory

Follow the sequence

  1. Ask delivery for the installed packrctl location and exact service release. Ask the service operator for its absolute local socket and running-state confirmation.
  2. Ask the product administrator to confirm CREATE_AUDIT_ARTIFACT permission; ask the Work owner for one unused approved key and a reviewer.
  3. Confirm access to returned report files or an approved copy procedure. A local socket is not a remote connection; a desktop terminal does not automatically reach the appliance.
  4. For a separate AI PoC, obtain supported model/location, identity/access, billing limit and storage/retention procedure. This audit example does not validate those connections or incur demonstrated AI usage.

Check the result

  • Every required handoff item has an owner and a verifiable value for the intended installation.

If it does not match

  • Missing startup/admin/AI/storage procedure: request it; do not create keys, grants, sandbox state or replacement binaries.
  • The separately repaired Admin demonstration candidate is not an existing Golden-operational complement or customer bootstrap.

Keep for the handoff

  • Version, target, approved scope and non-secret handoff confirmation; keep private endpoint/account details local
STEP 05

Query the same service and decide whether to stop

conditional existing operator

Record actual status and component reasons before submission.

Bring

  • Completed handoff
  • Fresh private output directory

Follow the sequence

  1. In the supplied local client environment, replace both absolute path placeholders, then use the baseline block. Keep the same shell/account/socket for following steps.
  2. Read status.json and health.json locally. Record the health exit and each relevant state/reason. A zero exit does not itself grant Work authority.
  3. If requirements are unknown or non-ready, ask the component owner to resolve applicability before submitting; do not repeat the lab’s exception by assumption.
Supplied operator reference · nothing runs on this page
PACKRCTL="/ABSOLUTE/SUPPLIED/PATH/packrctl"
SOCKET="/ABSOLUTE/SUPPLIED/PATH/control-plane.sock"
"$PACKRCTL" --help
"$PACKRCTL" --socket "$SOCKET" status --json > status.json
"$PACKRCTL" --socket "$SOCKET" health --json > health.json
HEALTH_EXIT=$?
printf '%s\n' "$HEALTH_EXIT"

Check the result

  • A timestamped baseline with liveness, readiness, authority/runtime observations and exit code.

If it does not match

  • Missing command: delivery/operator verifies installation path. Transport failure: operator checks endpoint/service. Authorization denial: administrator reviews binding.
  • Do not turn nonzero health into an automatic restart.

Keep for the handoff

  • Sanitized baseline summary; raw response files remain private
STEP 06

Submit one explicitly permitted audit operation

conditional existing operator

Create one intentional Work and keep its returned identity.

Bring

  • All operation-specific prerequisites resolved
  • Unused approved key

Follow the sequence

  1. Replace the key placeholder and keep the supported intent exactly as shown. Execute the submit block only for the separately authorized reproduction; reading this package does not submit anything.
  2. Open work-run.json locally. Save result.work.work_id with your key and exit code.
  3. The convenience command prepares and executes and writes records. Do not treat it as a read-only probe or generic AI prompt runner.
Supplied operator reference · nothing runs on this page
WORK_KEY="REPLACE_WITH_ONE_UNUSED_APPROVED_KEY"
"$PACKRCTL" --socket "$SOCKET" work run CREATE_AUDIT_ARTIFACT "create audit artifact" "$WORK_KEY" --json > work-run.json
RUN_EXIT=$?
printf '%s\n' "$RUN_EXIT"

Check the result

  • A response whose Work identity and outcome can be inspected; do not pre-fill success.

If it does not match

  • Timeout, missing ID, DENIED, STOP_WITH_FINDING, FAILED or PARTIAL: preserve the result and reconcile before further action.
  • execution_retry_allowed false forbids automatic retry. Re-running the helper is not exact prepared-envelope replay.

Keep for the handoff

  • Original key/request context, time, exit and exact returned Work ID
STEP 07

Reconcile and inspect that same Work

conditional existing operator

Prevent a second execution from being mistaken for recovery.

Bring

  • Exact returned result.work.work_id

Follow the sequence

  1. Paste your own Work ID in the query block; keep the original account and socket.
  2. Compare works[].work_id in list with work.work_id, reports[].work_id and selected_report.canonical_report.work_id in show.
  3. If absent from the last 10, show the saved ID directly or use the documented list limit up to 100. An empty scoped list is not proof of no Work anywhere.
  4. If submission returned no ID, preserve request context and ask support to reconcile the original installation/principal before another submission.
Supplied operator reference · nothing runs on this page
WORK_ID="PASTE_EXACT_result.work.work_id_FROM_work-run.json"
"$PACKRCTL" --socket "$SOCKET" work list --limit 10 --json > work-list.json
"$PACKRCTL" --socket "$SOCKET" work show "$WORK_ID" --json > work-show.json

Check the result

  • All inspected records refer to one saved Work; ambiguity is recorded rather than replaced by a new Work.

If it does not match

  • Identity mismatch, denied show or missing selected report: stop completion claims. Do not switch accounts to bypass a denial.

Keep for the handoff

  • Work ID, chosen report revision and sanitized reconciliation result
STEP 08

Read validation, receipt and closure together

conditional existing operator

Separate automated completion from human acceptance.

Bring

  • Same-Work show response

Follow the sequence

  1. Read selected_report.canonical_report: work_id, execution_count, final_result, validation_results, receipt and closure. Retain actual values, not the example’s expected values.
  2. Read closure.disposition, closure.human_acceptance_required and closure.human_acceptance. Read replayed and execution_retry_allowed in the returned result.
  3. PASSED is validation, not human acceptance. A replayed result is not a new execution. Missing receipt/closure needs support reconciliation.

Check the result

  • An accurate outcome statement; the retained example is automation completed with human acceptance pending.

If it does not match

  • Do not call FAILED/PARTIAL unchanged state or call a process exit product success.

Keep for the handoff

  • Sanitized outcome and pending reviewer decision
STEP 09

Obtain and verify the JSON and PDF

conditional existing operator

Review readable artifacts for the exact Work and revision.

Bring

  • selected_report.json_path and selected_report.pdf_path
  • Authorized local viewer or operator-supplied approved copies

Follow the sequence

  1. Use your returned paths, never a guessed report directory. Confirm files exist, are readable and match the selected Work/revision.
  2. On macOS the shared checksum block uses shasum; otherwise use the file verifier supplied for your platform. Compare JSON bytes to selected_report.projection.json_file_sha256 and PDF bytes to selected_report.projection.pdf_sha256, removing its sha256: prefix for comparison.
  3. Keep report_sha256 distinct from file hashes. It is the report digest, not the checksum of the saved JSON or PDF.
  4. Open the PDF in an authorized viewer and compare Work, execution count and validation with JSON. A server path is not proof of delivery to your computer.
Supplied operator reference · nothing runs on this page
REPORT_JSON="PASTE_EXACT_selected_report.json_path"
REPORT_PDF="PASTE_EXACT_selected_report.pdf_path"
shasum -a 256 "$REPORT_JSON" "$REPORT_PDF"

Check the result

  • Matched, readable JSON/PDF for one report revision. No separate underlying output artifact is promised by this step.

If it does not match

  • Missing/unreadable file or digest mismatch: retain the reference and ask the service operator/support; do not silently regenerate or substitute another report.

Keep for the handoff

  • Report revision, comparison result and minimal approved references; raw reports stay private
STEP 10

Review usefulness and record the human decision

planning

Answer the original PoC question without changing product acceptance by implication.

Bring

  • Plan criteria
  • Retained-run notes or actual eligible reproduction results

Follow the sequence

  1. The named reviewer compares the result with the agreed goal, permitted input, cost and retention boundaries. For the audit example, judge the structured artifact/report trace, not arbitrary content quality.
  2. Record the human’s review separately from the product’s latest closure state. This guide supplies no product acceptance command.
  3. If no provider was called or billing evidence was not collected, record not measured/not applicable with the reason; do not invent a cost or runtime result.

Check the result

  • A signed-off or unresolved human evaluation record and the separately observed product acceptance state.

If it does not match

  • A conversation approval or completed checklist must not overwrite AWAITING_HUMAN_ACCEPTANCE in reporting.

Keep for the handoff

  • Reviewer, date, criteria result, open issues and product state
STEP 11

Close the exercise and hand off remaining work

planning

Preserve required results and leave resources in an agreed state.

Bring

  • Exact resources used
  • Data owner retention choices
  • Operator’s supported stop/retirement procedure

Follow the sequence

  1. Reading-only route: retain your worksheet; there is no product process to stop.
  2. Operational route: ask the service operator to stop only an exercise-owned service when authorized by its supplied procedure. A closed GUI does not prove service shutdown.
  3. Have cloud/data owners review VM, disks, objects, backups and continuing charges separately. This guide provides no deletion or credential-revocation command.
  4. Send support the version, failed stage, expected/observed result, time, literal sanitized reason and minimal Work/report reference. Request a private channel before extra identifiers.

Check the result

  • A per-resource closure record with retained data, remaining charges and unresolved actions explicitly listed.

If it does not match

  • Unknown ownership or retention effect: stop deletion/restarts and ask the responsible owner. Never reuse test teardown as customer cleanup proof.

Keep for the handoff

  • Cleanup confirmations, retained-report location kept private, outstanding owner/action

Take the guide with you

Start with the blank input worksheet. Record your own observations separately from the historical example. Downloads contain no completed customer results.

Illustrative planning only

A small example of a scoped evaluation

Use this to understand the input fields. It records no new operation or approval.

goalUnderstand whether an approved audit operation can be traced from one Work to a readable report.
routeRead retained run first; consider eligible operator reproduction only after handoff.
inputSupported create audit artifact intent; no confidential document attachments.
acceptance criteriaIdentify one Work consistently; understand validation, closure and report-file hash checks; record reviewer disposition separately.
cost planNo provider action in the reading exercise; operational cost limit must be assigned by the owner before execution.
ownersPoC lead, service operator, product administrator and reviewer—assign actual names locally.
retentionKeep raw responses and reports private; share approved selected fields only.
unresolvedMatching installation and authority have not been claimed for this example.

Before you close the guide

Can I start if health exits 1 as in the recorded run?

No general permission follows from that history. The lab had separate approval and normal admission evaluated that operation. Resolve your own required readiness and authority before submission.

Is this an executable Pack I can import into Packtory?

No. This is a documentation package. It is not a registered payload, installed Pack, authority grant or product execution.

Can the audit command analyze my uploaded business document?

This registered operation creates a structured local audit artifact. It does not inspect arbitrary attached content.

What if the command times out?

Keep the key/request context and reconcile the original Work under the same installation/account. Do not submit a replacement or add an automatic retry.

Does the repaired Admin example unblock Golden r232?

No. It used a separately repaired task-local candidate and disposable target. It is not a Golden change, customer bootstrap or inherited production capability.

What do I send support?

Version, stage, expected and observed behavior, time and sanitized reason; minimal Work/report reference when appropriate. No credentials, raw reports, private paths, full logs or customer payloads.

What this edition establishes

  • Documentation-only local review package; Packtory registration and product execution not performed by this work.
  • Golden r232 remains immutable. New-customer C7 and full customer AI/storage/lifecycle procedures are not completed here.
  • Local R234 recorded Work is bounded evidence; this package creates no new runtime or production evidence.
  • Repaired Admin candidate complements the reference material, not the operational capabilities of existing Golden installations.
  • All command blocks are exact R17 references; placeholders need an authorized handoff. No historical rejected input is offered as a runnable test.
  • Raw JSON/PDF, execution responses, credentials and internal support exports are not public attachments.
  • Human review and product acceptance are separate; unknown values remain unknown.

This local Guide Pack is documentation. No new customer operation, Packtory registration or product execution occurred to create it.