Publish a pack to the store

Quick steps

01Set up the pack manifest (pack.yaml) with a reverse-DNS slug, name, and description.
02Bundle your plugin code, MCP server config, and contributed graphs.
03Write a structured changelog for the release (added / changed / fixed / breaking).
04Sign the pack archive with the [fix]net pack CLI.
05Publish to the store API — the version is immutable from this point.
06Verify the pack detail page renders correctly before sharing the link.

What goes in a pack

A pack is a signed archive. The store and the app both verify the signature before showing or installing it. Inside the archive:

pack.yaml            — manifest (slug, name, version, compat, license, …)
plugin/              — optional: plugin code (compiled or source)
mcp/                 — optional: MCP server definitions
graphs/              — optional: contributed graph definitions
assets/              — optional: icons, screenshots, README

You can ship any combination — a pack doesn't need all four. A plugin-only pack is valid; so is a graphs-only pack.

The manifest

pack.yaml is the single source of truth for the store and the app. Required fields:

slug: com.example.my-pack          # reverse-DNS, globally unique
name: My Pack
version: 0.1.0                     # semver
compat: ">=2.0.0"                  # minimum app version
license: MIT
description: "One-sentence description for the store card."
author:
  name: Example Corp
  url: https://example.com

Optional but recommended:

screenshots — list of CDN URLs; shown in the gallery island.
video_url — YouTube URL; shown in the gallery facade.
readme_md — extended Markdown description; rendered in the "About this pack" section.

Writing structured release notes

The store renders changelogs using a three-section structure. Your changelog field (or a CHANGELOG.md parsed by the CLI) must use this format:

changelog:
  added:
    - "New summarise node — condenses long threads into a bullet list."
  changed:
    - "Classifier requires app ≥2.0 (breaking — see migration note below)."
  fixed:
    - "Crash on empty mailbox fixed."
  breaking:
    why: "The classifier node's API changed in app 2.0."
    notes: "If you wired the output of the old classifier, re-wire it to the new summariser port."

The breaking key triggers the warning banner on the pack detail page. Don't omit it if there are breaking changes — users depend on it to decide whether to update.

Signing and publishing

Use the [fix]net pack CLI (part of the pack builder):

fixnet-pack sign --key ~/.fixnet/signing.key
fixnet-pack publish --api https://api.store.fixnet.se

The CLI validates the manifest, bundles the archive, signs it, and uploads to the store API. After publishing, the version is immutable — you cannot edit or retract it without publishing a new version.

After publishing

Check the pack detail page immediately after publishing:

Scorecard shows the correct version and compat range.
Changelog renders with the right sections.
Gallery shows screenshots if you provided them.
README renders in the "About this pack" section.

The store bakes pages from the catalog snapshot at deploy time; live API calls freshen the dynamic fields (rating, version). If you don't see your pack, wait for the next deploy or trigger a snapshot refresh.