Release v1.17.0

Changes

Added

• A standard submitted from the CLI can now carry its scope. A ## Scope section in a .packmind/standards/*.md file is read as the standard's glob patterns, so the coding agents that filter on file patterns get that filtering from a CLI publish instead of only from the web app. Patterns can be written comma-separated on one line or one per bullet. Standards distributed to .packmind/standards/ now render their scope in that same section, so editing the file and submitting it back keeps the scope instead of dropping it. Previously the heading and its patterns silently became part of the description
• packmind git track no longer sets the tracked branch to HEAD when no branch is checked out — a rebase in flight, a commit checked out directly, or a CI job on a pull request merge ref. It reports that no branch is checked out and names --branch <name> as the way to track one from there; git info and install describe the same state instead of claiming you are on a branch called HEAD (#758)
• Packmind now tells you when the branch it tracks has been deleted — the state a merged pull request leaves behind, in which nothing is recorded any more and nothing says so. The tracked branch is checked against the Git provider and flagged as "Branch deleted" on the repository cards under Settings → Targets and on the tracked-branch list of the Git connection panel, with the consequence spelled out and the recovery being to move tracking to a branch that exists. packmind git info reports the same state from the CLI, and packmind install no longer tells you to switch to a branch that is not there. Both web app markers need a Git connection to ask the provider with, so a repository Packmind knows only from packmind-cli install is covered by the CLI messages alone (#758)
• Check what Packmind tracks for the repository you are in with the new packmind git info command: it names the tracked branch, warns when the branch you are on is not the tracked one — distributions from there are not recorded — and tells you how to start tracking when the repository is not tracked at all. Reading the state needs no admin rights
• A marketplace with no Packmind plugin yet now carries the publish action instead of describing it, in one of three variants read from your data: the packages that can become plugins are listed with their space and their commands and skills, and each can be published from there with this marketplace already selected in the dialog; when none of your packages can become a plugin, the page states that a plugin needs at least one skill or command and links to each package so one can be added; when there is no package at all, it links to package creation in the default space. All three name the repository and branch behind the marketplace, so a marketplace linked to the wrong repository shows up immediately. When the marketplace descriptor already lists plugins Packmind does not manage, the page scopes its message to Packmind and counts those plugins instead of claiming the marketplace is empty.
• The marketplace page now checks the Git connection behind the marketplace when you open it, and leads with an alert whenever that connection is what blocks you: it names the connection, states the failure and the recovery in the same words as the Git page, and offers the repair before the re-check. When the credentials work again but the marketplace still carries the recorded authentication failure, the alert offers to reconcile it instead. A check that gets no answer stays silent rather than blaming the connection for a failure Packmind could not attribute.
• Packmind now renders into Kiro, which joins the other coding agents under Settings → Distribution → Rendering and is unchecked by default. Standards become one steering file each under .kiro/steering/, carrying their scope as a fileMatch inclusion so the Kiro IDE applies a scoped standard only to the files it covers — the Kiro CLI loads every steering file regardless of inclusion mode, so scoping is not narrowed there. Skills become one directory each under .kiro/skills/, and commands are not rendered since Kiro has no command directory — they stay reachable as @.packmind/commands/{slug}.md. Nothing lands outside .kiro/, and a removal or a cleanup only ever deletes the packmind-standard-* files Packmind named, never the steering files you wrote yourself. packmind config agents lists Kiro and detects it from a .kiro/ directory, and standards rendered into .kiro/steering/ parse back with their scope, so playbook diff and playbook add round-trip them like the Claude- and Cursor-rendered ones

Changed

• Breaking (CLI): packmind track and packmind untrack moved under the git command and are now packmind git track and packmind git untrack, joining packmind git info. Both flag spellings moved with them (git track --branch <name>, git track --update, and the two combined). The old names still parse but exit with an error naming their replacement, so scripts and CI jobs calling them must be updated
• The marketplace list now names the Git connection behind each marketplace ("via Acme GitHub") and states its health in words, replacing an 8px dot only readable on hover. Severity follows who has to act: a credential that stopped working or a transient failure is a warning an admin can clear from Packmind, while a repository that is gone or a descriptor that does not parse is an error nobody clears from here. The tooltip names the connection at fault and the recovery instead of restating the state.
• A disabled Sync button now names its cause: authentication when the connection's credentials stopped working, the repository when it can no longer be reached, the descriptor when it does not parse. It previously offered "Marketplace is unreachable or its descriptor is invalid" in every case, and never mentioned the one an admin can clear themselves. "Nothing to sync" still wins when no plugin has drifted.
• The Overview tab of a marketplace plugin now separates what the plugin ships from what it does not. Commands and skills are listed under "In this plugin"; the package's standards move to a "Not shipped" section stating that standards are distributed to repositories, not to marketplaces, with a tooltip explaining that the Claude Code plugin format has no slot for instruction files and pointing to repository distribution instead. Previously all three were listed together under "Bundled artifacts", which suggested standards were published to the marketplace when they never are.
• The "Publish to a marketplace" dialog now states what a publish will actually put on the marketplace — "Publishes 2 commands and 1 skill. 3 standards stay in the package: plugins don't carry standards." Previously it mentioned standards only when it refused a standards-only package, so a mixed package was published minus its standards without warning.
• On a marketplace with no plugin published yet, a publishable package now reads "2 skills, 3 commands · 4 standards not shipped" instead of listing the three counts together, so the standards are not presented as part of what the Publish button would send.
• The Packmind CLI is now packmind everywhere. The installer and packmind update maintain one real executable under that name and turn the older packmind-cli into a symlink to it, so packmind-cli keeps working and keeps receiving updates while printing a deprecation warning — it goes away in a later release. CLI messages now name the executable you actually invoked rather than hardcoding one, and the web app's setup, distribution and auto-update screens, the GitHub Actions workflow they generate, the documentation and the default packmind-onboard and packmind-update-playbook skills all say packmind. Repositories still on a CLI older than 0.34.0 keep receiving the skill wording that matches the executable they have (#772)

Fixed

• packmind git track --branch <name> no longer accepts a branch that does not exist. The name is checked against the branches of your repository — local ones and those already fetched from the remote — and a name Packmind cannot find is refused with the spelling and git fetch as the two things to check. A typo used to be tracked silently and only surfaced later, as distributions that were never recorded (#758).
• A connection created through the GitHub App now keeps the name you typed. The name travels with the install and is applied when the connection is created, including on-prem where the app is registered first and the name has to survive two round trips to GitHub. Previously it was dropped the moment you left for GitHub and every App connection came back as "Unnamed GitHub connection". If the name was taken by another connection while you were on GitHub, the connection is still created — unnamed, ready to be renamed — rather than the install failing (#743).
• A Git connection whose credentials no longer work can no longer be picked in the "Link a marketplace" drawer. Every connection is checked when the drawer opens, and one that cannot authenticate stays listed and named but is disabled, with the failure and a link to repair it under the field; it is no longer auto-selected either when it is the organization's only connection. Previously it passed the drawer's filter on having stored credentials and dead-ended on a repository list that failed to load (#751).
• packmind plugins render on a package that holds only standards now states why it cannot render, instead of failing with an opaque server error. The reason — a plugin needs at least one skill or command — was already carried by the error but never reached the CLI, which reported "Internal server error" and left nothing to act on. The marketplace publish path already explained itself; the CLI is the one route with no gate in front of it (#799)
• Editing a standard no longer marks the plugins published from its package as outdated. Drift is now measured over the artifacts a plugin actually carries — commands and skills — so a standard edit no longer raises "Changes to publish" nor opens a pull request that changes no file. For the same reason, the plugin "Changes" tab lists command and skill changes only.
• A Git connection can no longer be created or re-authenticated with a token its provider rejects. Both paths only checked that the credential fields were coherent, so a dead or scope-poor token was stored and reported as accepted while the connection could not list a single repository — and the re-authentication panel announced that the token had been "validated against" the host as it did so. The token is now checked against the provider before it replaces the stored one, and a token nobody can check is refused rather than reported as validated. Re-authenticating with a personal access token also works again at all: the drawer sent a body with the token stripped out of it, so repairing a connection ended in "Git provider update data is required" and a 500, and the provider edit form discarded a rotated token the same way. Renames, GitHub App rebinds and the tokenless providers the CLI creates are untouched — they neither pay for the check nor gain a new way to fail it

Docker Images

The following Docker images have been built and pushed to Docker Hub:

• packmind/api:1.17.0
• packmind/frontend:1.17.0

All images are also available with the latest tag.