Share Knowledge the same way you share Providers and Skills

This sprint

Agents could already reach support Knowledge over MCP (knowledge://support/* and search_support_knowledge). Operators could already install Provider packages and Skill Packs from a trusted Marketplace aisle. Knowledge was still something you authored on this appliance: Doc Sources, default docs paths. You could not package a support corpus slice and install it the way you install a Provider or a Skill Pack.

Sprint 107 closes that gap with thin Knowledge Pack share-install: package Knowledge documents, list them in the same appliance-local catalog (pack_kind: knowledge), then install-from-catalog with a checksum check before anything lands. Pack docs merge into the support-retrieval corpus. They show up on knowledge://support/* and in search_support_knowledge, on HTTP /mcp and stdio.

This is still share and trust for your appliance, not a public community storefront, and not a Knowledge CMS.

What moved

A Knowledge Pack is a directory with a manifest.yaml: who it is, which documents it contributes, and a catalog checksum over the pack files. It does not invent a second Knowledge store. After install, those sources are listable and readable as knowledge://support/sources/… and searchable with search_support_knowledge.

You browse Available packages, then install by id. The appliance verifies the checksum, copies the pack, ingests the documents, and refreshes MCP Knowledge surfaces. Uninstall removes those pack docs only — not Doc Sources customs, not Providers, not Skill Packs.

Built-in support docs and Doc Sources are unchanged. Playbook RAG packs stay out of this slice. Shareable org Knowledge uses the support aisle.

Still open

On purpose, this slice does not add:

• A public community Marketplace, publisher accounts, or ratings
• A Knowledge CMS (Doc Sources still covers local authoring)
• Playbook-corpus packaging
• A hosted remote catalog / CDN

For customers

• In the IDE: after Install, new support Knowledge resources and search hits appear on the same BacklogZero MCP connection — same token, same Connect panel. You are not wiring a second MCP server because a Knowledge Pack landed.
• For operators: ship a curated support-doc pack beside Provider and Skill packages in one trusted catalog. Discover it in Available packages; see it on support Knowledge list/search after Install.
• For the product: Providers still extend the tool surface; Skills still customize behavior; Knowledge still informs agents. Share for Knowledge now matches the Provider and Skill paths: package → trusted catalog → install.

Sprint 97 made support Knowledge reachable. Sprints 105–106 made Providers and Skills installable. This sprint makes Knowledge installable from the same aisle.

Signed-in tour: UI features (MCP Connect → Available packages). PAT and transport: MCP quickstart.

Try it (about five minutes)

Goal: browse the trusted catalog, install a Knowledge Pack, see the docs on support Knowledge, then uninstall — without editing BacklogZero core. Sign in; mint a PAT from Configuration → MCP Connect if you will use HTTP MCP.

1. Browse Available packages

Configuration → MCP Connect → Available packages. You should see a Knowledge Pack (lab fixtures include Sample Knowledge Pack) with an Install button, alongside Provider and Skill packages.

2. Install from the catalog

Install. The catalog checksum is verified before documents land in support-retrieval. Providers, Skill Packs, and Doc Sources customs are not modified.

3. See it on support Knowledge

On MCP (HTTP /mcp or stdio):

List knowledge://support/catalog (or support sources) and search_support_knowledge
for the pack content. Confirm a hit that belongs to the installed Knowledge Pack.

Available packages should show the pack as Installed.

4. Uninstall (clean slate)

Uninstall drops pack docs only. Other support sources, Providers, and Skill Packs stay. Anonymous install still returns 401.