01 · Product and review baseline
VibePackr is a dedicated, single-tenant VM appliance in the customer’s Google Cloud project, operated headlessly by default. The documentation baseline is 0.1.0-r232. The exact final customer delivery version and Marketplace deployment package are pending. No successor version is assigned by this guide.
Use the English Customer & PoC Getting Started as the primary procedure. The Developer Guide is supplemental context for integration preparation; it does not replace customer deployment instructions.
For a reader new to VibePackr, begin with the customer guide’s orientation, roles and access example and illustrative PoC. These explain the same procedure below; the example is conceptual and is not execution evidence.
02 · Access, inputs and costs
- An agreed review scope, authorized contacts, Google Cloud project with billing, intended zone and VPC/subnet.
- Supplier-provided listing/preview access, exact deployment package/version, offer/terms and resource inventory. These final customer inputs are pending.
- Supported maintenance access and separately established product administration. Retained IAP SSH access is not product administrator issuance.
- For AI: permitted project, location, model and service identity; API, model access, network and billing conditions. Customer-VM setup remains unvalidated.
- Software charges are separate from Google Cloud infrastructure and AI-service charges. Stopping/deleting a VM may leave retained storage and related charges.
The reference sizing is e2-standard-2 (2 vCPU, 8 GiB), Debian 13 x86_64, 20 GiB boot disk, with separate 50 GiB durable-disk and 100 GiB live-object-storage planning figures. It is not a performance guarantee, universal minimum or proof that those resources are provisioned. See deployment preparation.
03 · Recommended reading and verification route
| Read the shared customer procedure | Result to inspect | Current validation state |
|---|---|---|
| Preparation → Marketplace entry | Agreed contacts, costs, offer, exact listing and delivery version | Final listing/package/offer inputs pending |
| Deploy → Access | Correct VM/resources and supported SSH access | Retained bounded raw-image deployment and IAP SSH; exact customer Marketplace-package replay pending |
| Initialize / health | Base health result and separate unevaluated fields | Bounded retained evidence; not overall readiness |
| First administrator | Supported issuance and permitted product access | Policy approval / implementation / customer validation pending; stop dependent execution |
| AI → Storage | Actual customer identity/model/storage behavior | Implementation and limited prior evidence exist; exact customer setup and execution remain pending |
| Readiness → First work item | All required checks and agreed work outcome | Overall new-customer readiness and replayable first-work sequence unproven |
| Stop/restart → Retirement | Intended state transition and per-resource retention/deletion | Retained storage tests are limited; final customer lifecycle instructions pending |
Follow these links rather than a duplicate procedure. Record the observed result and stop at the first unmet prerequisite. No missing step should be treated as a successful test.
Read a concrete integration example
- Open the complete CUSTOM_API source document and its field table.
- Compare the local discovery result with the deliberately unbound-target denial. These are selected actual local fields, not a customer E2E run.
- Inspect GAPE, external-agent assistance and Vertex runtime distinctions.
- Use the remaining self-service conditions to identify what a reviewer cannot yet reproduce from downloads alone.
Read the operational surfaces
Headless covers terminal operation; PackrGUI covers the desktop client; VibePackr Admin and Packtory Admin separate management roles. Troubleshooting provides symptom-based next actions. These source-derived references do not close first-administrator setup or establish customer execution. Inspect each guide’s source/delivery scope before using a desktop screen as an appliance delivery claim.
Review a task from start to finish
Usage workflows connects the five surfaces through inputs, one submission route, same-result checks and owner handoffs. The separate Packtory library guide covers search, inspection and conditional download/derivative demonstrations. These inspected adapters use sandbox configurations; general customer production delivery is not established.
Inspect one actual Headless run
Open the six-step recorded-run reader, then the operating prerequisites and command guide. The reader connects the actual rejected input, correction, one local R234 Work, same-Work readback and report verification. It shows selected recorded fields rather than a live terminal. Validation PASSED and product human acceptance pending are separate recorded states. This local exercise is not a customer r232 Marketplace deployment.
Review workspace coverage without assuming every branch ran
The workspace menu map covers Business, all eight Engineering IDE stages and its five related tools, and all six Operations routes. The actual audit Work and additional native observations anchor the instructions. Populated source-change/build, policy administration, AI calls and human acceptance were not executed by this walkthrough. Read the stated observed result and remaining branch for each menu.
04 · Google guidance and this draft
The following distinguishes Google’s published guidance from this documentation’s editorial recommendations. It is a mapping, not a compliance or submission claim.
| Source | Official guidance | Current disposition |
|---|---|---|
| Getting Started | A Google Cloud-specific Getting Started document must be created and maintained on the supplier’s website. It should cover listing through deployment and maintenance, required inputs, additional configuration, access and health. | The R17 English Headless and GUI walkthrough review edition is available on this website. Complete customer procedure remains pending. |
| Same guidance | Screenshots are recommended. The page suggests Google Cloud co-branding. | These are recommendations. Earlier native views are retained; 17 additional actual local GUI workflow views cover the three workspaces and report route with explicit scope labels. A matched customer deployment/administration journey remains pending; no simulated screens are used. |
| Same guidance | If login is required, explain administrator access and credential acquisition. If an administrator page/console requires a password, it must be auto-generated. | Applicability and the supported first-admin procedure require confirmation. This statement does not select or implement a VibePackr credential policy |
| Same guidance | Email the draft URL to the assigned Partner Engineer for review and feedback. | This R17 English review edition is published; Google feedback submission is not recorded. |
| VM product testing | Preview requires the deployment object to be uploaded and validated. The page recommends end-to-end flows, checks listing/deployment behavior and says to test post-deployment steps documented in Getting Started. | Portal preview, listing/UI, license association, machine-size/region/clone coverage and customer post-deployment replay remain separate validation requirements; they were not executed here |
Editorial recommendation: use one customer guide for both customers and reviewers, plus this short navigation document. The two cited pages do not establish a universal requirement to submit the entire SDK documentation. Any product-specific Partner Engineer request remains separate.
The official test page includes generic console, role and legacy deployment references. This guide does not turn them into a product-specific IAM grant, deletion instruction or selected deployment implementation.
05 · Known limits and feedback request
Please review whether the shared customer sequence, expected results and pending conditions are clear. Comments on documentation can proceed before product readiness is established.
- Initial administrator policy is under review; issuance, successor implementation and validation remain pending.
- AI identity/setup, production storage binding, entitlement verification and complete lifecycle behavior require exact customer-path validation.
- Helper/SDK customer delivery and approved public successful-input schemas remain pending. Architecture planning does not create product authority.
- The exact Marketplace package, final delivery version, access instructions and matched customer-journey screenshots remain dependencies.
- Local HTML authoring, public URL availability, feedback submission and final customer reproduction are separate states.
Support: support@vibepackr.com. Send the version, step and sanitized error or documentation question. Do not include secrets, full logs or confidential work. No response-time commitment is made here.
New R2 examples improve source-document authoring and error interpretation. They do not supply a fully distributable Helper request envelope, a validated customer agent version, or completed Linux Vertex binding. Local source discovery, syntax checks and browser checks are separate from Marketplace product validation.
The earlier R6 documentation work retained five native views and did not submit product Work. A later isolated local R234 Headless exercise did complete one actual Work with same-Work readback and report verification. R8 integrates its selected recorded fields; this integration starts no new Work. Product acceptance was not updated by the later approval of the exercise and guide. Connected customer GUI sequences remain unproven; see the per-surface evidence table.
Inspect the actual GUI report route
R9 adds one different isolated R234 Work submitted from PackrGUI. Follow Business, Engineering, Operations and the final report guide. The PDF viewer opened the same Work report, both file hashes matched, and product human acceptance remains pending. This is local candidate evidence, not customer Marketplace delivery or Google approval.