Part.1 · Installation and first connection
OS preparation, installation, first connection and checks
Open Part.1 manual →VibePackr Enterprise · Manual series
Documentation · Parts 1–8
Client and AI agent setup reference
For initial setup start with Part.1. The client guide covers OS-specific installation and local manuals; Skill.html displays all common Skills, MCP instructions and planning worksheets. For a later legacy/runtime addition or interruption, continue in Part.8.
Part.1 · Agent setup · Client guide · Skills / MCP / TOML · Part.8 · Recovery and expansion
Guide connections, workflow and input/output map
Use Part.1 for installation, then select the Part for your tool. Each Part includes prerequisites, exercises, inputs/results, repeated use and troubleshooting. You do not need every tool.
First visit: start with Part.1 installation →
Choose a Part
Part.2 · GAPE observation, comparison and sharing
4 detailed operating exercises plus existing first-use and troubleshooting
Open Part.2 manual →Part.3 · Integration Helper operation
4 detailed operating exercises plus existing first-use and troubleshooting
A: plan before declarations. B: validate after completing declarations.
Open Part.3 manual →Part.4 · Contract and Document authoring
4 detailed operating exercises plus existing first-use and troubleshooting
Open Part.4 manual →Part.5 · SDK Engine practice and candidates
4 detailed operating exercises plus existing first-use and troubleshooting
Use when adapter implementation is needed. Skip authoring for an existing implemented, registered, release-compatible integration.
Open Part.5 manual →Part.6 · Builder and Additional Packs
4 detailed operating exercises plus existing first-use and troubleshooting
Use to author a new Pack. Skip authoring when an existing approved Pack meets the goal and installation scope.
Open Part.6 manual →Part.7 · PackrGUI and headless operation
4 detailed operating exercises plus existing first-use and troubleshooting
Open Part.7 manual →Part.8 · Operations, troubleshooting and support
4 operating procedures and 30 detailed A–J scenarios
Open Part.8 manual →How to read numbers and file names
Part.1–8 identifies the current tool manuals. W1–W4 and codes such as GUI-01 identify exercises inside a Part. Use Case 1–5 is a separate retained procedure sequence, not the Part numbering. Case A–J and codes such as SDK-1 or IH-1 identify troubleshooting scenarios. Older filenames and pN section IDs remain valid bookmarks; read the page heading for the current Part number.
Full workflow, both Helper phases and SDK/Builder skip conditions
Choose the kind of work first
You do not have to run every tool after installation. The recommended path below is for a new integration and a new Pack. Part numbers now follow the normal authoring and usage flow. Return from Part.4 declarations to Part.3B validation; skip SDK or Builder authoring when it is unnecessary.
- Installation and environment — Part.1: prepare the required tools, OS and any Appliance/client connection needed for your task.
- Understand the structure with GAPE — Part.2: read components, interfaces and revisions in the supplied approved snapshot/viewer. Only an owner with an approved manifest and source creates a new snapshot. Reuse an established observation for a simple known integration.
- Plan with Integration Helper — Part.3: identify the capability, exact target, required inputs, mappings and implementation gaps. GAPE-bound
r2-plan-architecturerequires that release's complete planning input and existing Contract, registry, owner and authority references. This differs from the laterr2-discoverrequest. Do not pass this manual's Custom API exercise JSON to the planning command. - Write the Document and bind the Contract — Part.4: complete source API/MCP schemas, required fields, synthetic fixtures and explicit mappings. Select the exact target Contract revision already published by the supplier. Customers do not issue a new product Contract here. Planning in step 3 already needs the relevant target references.
- Validate and prepare with Helper — Part.3: use the complete request for discover → normalize → validate → prepare → status, checking each result. Resolve refusal or implementation-needed results. After editing a declaration, return to affected validation.
- SDK Engine when a new adapter implementation is needed — Part.5: create an analyze/generate/build/validate/package candidate from supported declarations. Inspect
adapter.rs,libadapter.rlib,README.mdandmanifest.json. This candidate uses synthetic data and does not prove live API transport implementation, authentication or a production connection. Complete any required implementation/review and hand over through the release's separate registration path, checking its actual result. Skip this step for an existing implemented integration. - Builder when a new Pack is needed — Part.6: use exact capability/integration references confirmed usable to compose inputs, outputs, preconditions and failure handling; validate the Pack candidate. This guide provides no automatic copy/import of the SDK
.rlibinto Builder. Skip Pack authoring when an existing approved Pack meets the need. - Operate after validation, approval and entitlement — Parts.7/8: check Pack/integration registration, Work binding/approval and current preconditions separately. Use the approved PackrGUI or headless route and reconcile the outcome with its receipt. This documentation task does not activate/deliver to customers or execute customer Work.
Why Helper appears twice
First it helps plan what connects where; later it validates the completed declaration, target and mapping. This does not mean every Helper command can run without a source declaration. Obtain published target Contract references before planning, then refine the source Document and mapping using Helper results. SDK and Builder cannot substitute for missing declarations.
Three paths through the tools
| Situation | Path | Handover |
|---|---|---|
| Use an existing approved Pack | Install/connect → GUI/headless → current authority/preconditions → check Work outcome | Exact Pack, installation and Work references; receipt |
| Compose a new Pack from registered capabilities | Install → verify existing capability/target → Builder → candidate validation, approval and use | Capability revision, Pack candidate, validation and approval records |
| Add a Custom API integration and a new Pack | Install → GAPE → Helper planning → Document/target → Helper validation → SDK if needed → separate implementation review/registration → Builder → approved use | Inputs, revisions, typed decisions, candidates and unresolved items for each stage |
Entry, return and handover points
| What you have or where you are blocked | Next action |
|---|---|
| A GAPE viewer without source access | Read the approved supplied viewer's scope. Do not collect source for an unauthorized scan. |
| No published target Contract or planning input | Obtain supplied references. Do not match targets by display name. A source Document draft can proceed independently. |
| Helper refuses mappings, required fields or target revision | Correct the affected declaration in Part.4 and return to the affected Helper stage. |
| Helper scaffold says REQUIRES_IMPLEMENTATION | Check Part.5's supported scope and identify the implementation owner. Scaffold generation/SDK build does not prove a live connection. |
| An SDK candidate without registration | Hand the candidate and validation scope to the separate registration owner. Do not automatically promote it to Builder/Work use. |
| A validated Builder candidate awaiting approval/entitlement | Preserve it and obtain actual results for the exact approval and installation scope. Record validation and use separately. |
Online and offline environments can follow the same workflow. The optional SDK Rust set chooses a build environment; it is not the whole product's default operating mode.
Local documentation edition. Company connection, approval and enrollment require actual supplied material. Educational scenarios are not customer execution evidence. Apple signing/notarization and customer activation/delivery remain held.
Connect the Guides and Parts 1–8
Choose a purpose in a Guide, then use the relevant Part for exact tool steps. The same sequence, vocabulary and artifact roles apply in both.
Purpose guides
- Common PoC Guide
Choose a question, collect scoped observations and review the result. A retained-reading route needs no new installation.
- Google Reviewer Guide
Bind the exact review delivery and criterion evidence. Cloud access, document coverage and actual Google approval remain separate.
- On-premises Guide
Prepare the exact OS, package, network choice and toolchain. Use the local SDK shortcut only after its prerequisites are supplied.
- Custom Execution Guide
Choose a supported task. Keep source-document preparation, full SDK candidates and actual Work/report inspection as distinct routes.
- Guide links open the public website and require network access; this offline manual and its local examples remain readable without it.
Recommended integration order and shortcuts
- Part.1 · Install and prepare
- Part.2 · Observe structure with GAPE
- Part.3A · Plan with Integration Helper
- Part.4 · Write the source Document and bind the published target Contract
- Part.3B · Check the complete request and identify implementation needs
- Part.5 if needed · SDK candidate, implementation review and separate registration
- Part.6 if needed · Builder Pack candidate and its approval path
- Part.7 · Permitted GUI or headless operation
- Part.8 · Results, troubleshooting and human review
Helper B checks the completed declarations before you decide whether implementation or a new Pack is needed. After an implementation or declaration change, repeat only the affected supported checks and finish the separate implementation/registration/Pack approval path before operation. A generated candidate grants no operating authority.
Select only the route needed for your goal. Retained PoC reading can begin without installation. A supplied local SDK exercise uses Part.1 → Part.5 and does not require a new GAPE scan or appliance account. An existing approved Pack can use Part.1 → Part.7 → Part.8 after its current prerequisites are checked. New integration/Pack authoring follows the full conditional sequence.
Part map and tool responsibilities
| Part | Role and expected boundary |
|---|---|
| Part.1 · Installation and first connection | OS preparation, supplied packages and first connection. Installation is not an executed Work. |
| Part.2 · GAPE observation, comparison and sharing | Revision-bound architecture observation. A worksheet is not the approved GAPE input manifest. |
| Part.3 · Integration Helper operation | A plans before the Document; B checks the completed full request. Each stage reads its typed status/reason. |
| Part.4 · Contract and Document authoring | Author the source Document and mappings; use the supplied target Contract/revision. JSON syntax alone does not establish semantic compatibility. |
| Part.5 · SDK Engine practice and candidates | Generate a local SDK implementation candidate. Reuse an implemented, registered, release-compatible integration when it already meets the need. |
| Part.6 · Builder and Additional Packs | Prepare a Pack candidate when a new Pack is needed. Reuse an existing approved Pack that meets the goal and installation scope. |
| Part.7 · PackrGUI and headless operation | Use the supplied GUI/headless route under its current authority and preconditions. Inspect the returned Work identity and result. |
| Part.8 · Operations, troubleshooting and support | Compare same-Work artifacts, receipt and closure; keep human acceptance pending until actually recorded. |
Shared vocabulary
- Guide / Part
- A Guide is a purpose/role route; a Part is a tool reference. They complement each other and are not two competing numbered workflows.
- Contract / source Document
- The published target Contract defines the supported target and revision. The source Document declares your source shapes. A source declaration does not authorize execution.
- Complete request / source-only file
- A complete SDK request includes request_id, correlation_id and draft with definition/source/mapping/fixture. The source-only status Document is one component, not that complete request.
- Fixture / actual observation
- A fixture supplies synthetic values for a declared local exercise. Its declared fields do not prove a real provider call, current connectivity or a customer result.
- SDK candidate / Pack candidate
- The SDK candidate has README.md, adapter.rs, libadapter.rlib and manifest.json. A Builder Pack candidate is a separate product-returned candidate with its own validation/approval path. Neither automatically becomes an approved Pack.
- Worksheet / receipt / acceptance
- A worksheet records a human note. A receipt is a product execution record. PASSED validation and automation completion can coexist with human acceptance pending; record each field at its actual scope.
- Online / Offline
- These are setup choices. Offline product development requires the exact declared dependency set and native tools; an offline manual ZIP only supports document reading.
Match each input to the right output
The status.read source-only example and the read_quality SDK exercise are different examples. Use a matching complete request; do not pass the status source file directly as the quality SDK request. Expected mapping values below are teaching expectations, not a newly captured run.
| File / role | Input | Output / check |
|---|---|---|
status-document.jsonSource-only CUSTOM_API declaration for status.read. Use it inside the complete supplied preparation request. | service: string | Declared service: string and healthy: boolean. This is a schema, not an observed service response. |
read-only-custom-api.json / custom-api-01.jsonThe complete maintained SDK base request; the guide copy is byte-equivalent JSON. | fixture.response.component = "fixture-component"; score = "97" (string) | STRING_TO_INTEGER maps score to expected integer quality_score 97. The documented SDK result is a local candidate. |
custom-api-02.jsonA complete second SDK request changing only the two fixture response values. | component = "my-test-component"; score = "88" (string) | Expected mapped component is "my-test-component" and quality_score is integer 88. Inspect actual manifest/stages; identical mapping source is possible. |
custom-api-score-number.jsonIntentional negative input, not a successful base example. | fixture.response.score = 88 (JSON number) against a declared string schema | Keep the actual typed failure result. Do not convert the example into a claimed successful candidate. |
Worksheet / SDK artifacts / Work reportsThree different artifact classes: human notes, local compiled candidate, actual Work/report/receipt records. | Use the matching tool and current target; never submit a worksheet or previous result as the next full request. | Bind outputs to the actual input, version, candidate or Work identity. File presence and exit 0 alone are insufficient. |
A conceptual view of complexity and the user experience
User-provided conceptual illustration. The n(n−1)/2 table is a theoretical upper bound for a simple undirected graph, not a measured integration count or benchmark. Listed components/features remain release-specific; this is not evidence of reviewer access or customer execution. The displayed edition is an English SVG with current documentation updates; the earlier raster original remains preserved.
Use online or download for offline use
The download contains the same Parts, images and synthetic exercise inputs. Extract the entire ZIP, then open index.html. No server or internet connection is needed to read the manual; product installation and SDK toolchains have their own prerequisites.
Additional technical references
Technical references complement Parts 1–8. Their dated examples keep their stated scope.
Operations and administration
PackrGUI workspaces
Packtory and built-in Packs
Integration and AI
Recorded examples
Reference scope
Each retained reference states its own date, environment and limits. Reading a reference does not install, activate, register or execute a product.