Haptique OS Docs

Appearance

Haptique Kitchen ​

Haptique Kitchen is the local-first community extension system for Haptique OS. It is backed by a public GitHub registry, but installation and review happen inside the local OS product.

The Kitchen flow does not replace Fleet cloud integrations, Fleet backend registration, or legacy /integration/... routes. Kitchen is an OS-local extension path that can coexist with the AWS-hosted Fleet product.

Registry Model ​

The public registry is:

text
https://github.com/Cantata-Communication-Solutions/haptique-kitchen-registry

Haptique OS reads the generated catalog from:

text
https://raw.githubusercontent.com/Cantata-Communication-Solutions/haptique-kitchen-registry/main/catalog/index.json

The registry stores package metadata only. Developers keep source code, issues, changelogs, and release ZIPs in their own public GitHub repositories. A registry package points to that developer-owned repo and, when installable, to a release ZIP plus its SHA256 hash.

Package metadata lives under paths such as:

text
packages/drivers/com.vendor.driver-name.json

Package Types And Trust ​

Kitchen package types:

  • driver
  • widget
  • recipe
  • scene
  • builder-template

Trust levels:

  • community
  • verified
  • core-candidate
  • built-in
  • deprecated
  • blocked

Community packages can later be promoted through review into Verified, Core Candidate, and eventually core OTA delivery when they become product-owned behavior. Promotion should add OS behavior without breaking Fleet compatibility.

Logical Device UI Boundary ​

Kitchen drivers do not own the main Logical Device page. Drivers declare capabilities, permissions, device class, command hints, and optional UI hints. Haptique OS renders the default Logical Device UI from that contract.

Optional widgets or advanced panels may ship as separate Kitchen surfaces, but they must not replace OS navigation or take ownership of the OS-rendered Logical Device page.

AI Driver Builder Submission Flow ​

AI Driver Builder artifacts can prepare Kitchen submissions from generated driver ZIPs. The OS-side flow calculates the local artifact SHA256 and validates registry fields before showing the package as PR-ready.

The current Beta flow is:

text
Search Kitchen
-> no package found
-> open AI Driver Builder
-> generate and test local driver
-> prepare Kitchen submission
-> publish source and release ZIP in developer GitHub repo
-> submit registry PR
-> registry CI validates listing
-> maintainer reviews and merges
-> OS Kitchen catalog refresh shows the package

Prepare Kitchen Submission produces:

  • Registry package JSON.
  • Target registry path.
  • Local ZIP SHA256.
  • Validation result and missing fields.
  • Submission bundle ZIP with README-submission.md.
  • PR checklist covering install testing, uninstall or rollback, permissions, secrets, Logical Device UI, and external dependencies.

The registry validation command shown by the OS is:

bash
npm install && npm run validate

Install Review ​

Before installing a community package, Haptique OS shows an install review gate with:

  • Trust level.
  • Requested permissions.
  • Source repository.
  • Artifact URL.
  • SHA256 verification state.

The downloaded ZIP hash is verified before the OS calls the local driver package installer.

The OS Kitchen page also exposes package details for status, trust level, permissions, compatibility, Logical Device UI hints, source repository, artifact URL, and SHA256. Uploaded local drivers can be updated from a newer installable listing or uninstalled/rolled back after active integrations using that driver are removed. Built-in drivers are not removed through Kitchen.

Cross-References ​