Who’s running what
Every customer using each pack, which version they’re on, and the automatic upgrade that keeps them current.
When a new version of a pack goes live, a background job periodically visits every customer using that pack and upgrades them to it. Customizations survive: any pieces a builder or customer replaced for themselves are stored separately, so the upgrade slides in underneath their tweaks without touching them.
Packs that build on other packs install foundation-first — and if a foundation hasn’t been released yet, the install stops loudly rather than shipping something incomplete.
By pack
Live version vs what’s actually installed.
| Pack | Live version | Installed | Status | |
|---|---|---|---|---|
| legal-practice-v1 | v2 | 10 on v2 · 2 on v1 | 2 behind | |
| construction-field-v1 | v1 | 4 on v1 | All current | |
| platform-base | v4 | 16 on v4 | All current |
Behind this page/templates/harnesses/installations · catalog publisher/validator
Retrieve
sp_GetPublishedHarnessVersions gives the published census; installed state lives in ai_harness_installs per tenant AI DB. This UI needs an aggregated install-census reader (gap) rather than walking databases.Save
Queue re-install marks tenants for the sweep worker, which re-runssp_ai_harness_install using sp_GetPublishedHarnessPack (BasedOn chain, base-first).Success
- Overrides survive: tenant / builder layers are separate rows.
- The sweep is scheduled; this page shows its cadence and last result.
- Provenance columns keep the link back to the library version for drift detection.
CLI handoff
Implement this scaffold from the structured contract, then remove hard-coded preview rows. The source of truth is CLI Handoff and admin-cli-manifest.json.
Server-inject identity and scope values; never trust browser-supplied account, app, tenant, user, entitlement, price, or permission identifiers. Preserve the loading, empty, forbidden, failed, retrying, and completed states shown by the preview.