Skip to content

Read the inventory by state and by frontmatter - #11

Merged
migsilva89 merged 1 commit into
mainfrom
inventory-filters-and-universal-build
Sep 7, 2026
Merged

migsilva89 merged 1 commit into
mainfrom
inventory-filters-and-universal-build

Conversation

@migsilva89

Copy link
Copy Markdown
Owner

Closes #3. Closes #10.

What changes

A plugin that is off now turns off what it ships. Its skills, commands and subagents kept their rows lit and their switches on, so the list claimed Claude was loading things it was not. They now read as off everywhere they appear, and stay visible under the Off filter — the only place you can put them back from. Their switches stay still until the plugin is back on: on the row, in the detail pane, in the plugin's own page, and in the row's context menu.

The Off filter has an opposite. Every kind — skills, commands, subagents, MCP servers — now has On beside it, and the two partition the list.

Frontmatter is data, not just text under the file. Every top-level key a file happens to set appears on its own in the funnel and the sort menu, and the chosen one becomes a small column on each row. No key names are hard-coded, so a field one assistant invented does not show up on another's files.

Releases run on Intel Macs. Scripts/build-app.sh builds arm64 and x86_64, and refuses to assemble a bundle whose app or embedded Sparkle framework is not universal.

Two smaller fixes found while testing the above:

  • A skill live in one assistant and parked in another shared an id with itself, so SwiftUI drew one row and left a blank gap the size of the other, with every count one too high.
  • A second snapshot of a shared skill within the same second failed with "an item with the same name already exists" — the first snapshot had become a link to a file that had since moved, and the free-name check followed the link instead of seeing it.

Spec

New acceptance criteria in docs/SPEC.md: AC2.8 (On/Off on every kind), AC2.9 (dynamic frontmatter filter and sort), AC3.14 (a disabled plugin's children), AC9.9 (universal binary).

How it was verified

  • swift test — 312 tests, 0 failures.
  • swift run LoadoutApp --self-check — 135 checks.
  • lipo -archs on the release bundle: x86_64 arm64 for the app, Sparkle, Autoupdate and Updater.app.
  • Driven through the app's own controls with LOADOUT_DRIVE against a fixture home: three rounds of off/on on a skill without error or losing the selection; On + Off summing to the total on all four tabs; a plugin turned off keeping its skill, command and subagent visible under Off; two same-named skills producing two real rows with distinct ids; frontmatter filter and sort appearing per tab and resetting on a tab change.

Three things the list could not answer.

A plugin turned off left every skill, command and subagent it ships with its
row lit and its switch on, so the list said Claude was loading things it was
not. They now read as off wherever they appear, and stay visible under Off,
which is the only row you can put them back from. Their switches — on the row,
in the detail pane, in the plugin's own page and in the row's context menu —
stay still until the plugin itself is back on.

The Off filter had no opposite. Every kind now has On beside it, and the two
partition the list.

Frontmatter was text under the file and nothing more. Every top-level key a
file happens to set now appears on its own in the funnel and the sort menu, and
the chosen one becomes a column on the row. No key names are written down
anywhere: a field one assistant invented simply does not appear on another's
files.

Two smaller things, found while testing the above. A skill live in one
assistant and parked in another shared an id with itself, so SwiftUI drew one
row and left a gap the size of the other. And a second snapshot of a shared
skill in the same second was refused with "already exists", because the first
had become a link to a file that had moved and the free-name check could not
see it.

Releases are now built for Apple silicon and Intel, and the build refuses a
bundle whose app or Sparkle framework is not universal.

Closes #3
Closes #10
@migsilva89
migsilva89 merged commit 1f2db36 into main Sep 7, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Ship a universal binary so Loadout runs on Intel Macs Sort and filter by any frontmatter key

1 participant