Skip to content

HubPanel: pull and bundle-build actions - #57

Merged
w4ffl35 merged 4 commits into
mainfrom
feat/hubpanel-actions
Oct 14, 2026
Merged

w4ffl35 merged 4 commits into
mainfrom
feat/hubpanel-actions

Conversation

@w4ffl35

@w4ffl35 w4ffl35 commented Oct 14, 2026

Copy link
Copy Markdown
Member

Closes #47.

What

  • Community catalog entries get a pull button sending protocol-1.1 hub_pull, with progress streamed from hub_pull_state through the existing download-progress UI (including cancel).
  • Saved models get a build button in the bundle tab sending bundle_build, surfacing the returned path, size, and sha256.
  • useHub exposes pullEntry/buildBundle with progress state, mirroring the reference hook from spikeforge#81.
  • Failures render the specific error text the server sends. Against a pre-1.1 server — which answers the unknown action type with a validation error — the UI names that explicitly ("does not support pull/bundle build, needs protocol 1.1 or newer") instead of hanging in a progress state.
  • Mirrors protocol 1.1: both envelopes, protocol_version.txt, regenerated generated.ts (diff is exactly the new types + 1.1). Negotiation is major-only, so 1.0 servers keep working for every other action.
  • The bundle tab moves into ModelBundleTab, which also brings ModelPanel back to the 200-line component limit.

Notes for review

  • useHub is 190 lines against the 120-line hook guideline; the new in-flight/error-capture logic lives in its own useHubPendingAction hook, and the remainder is the spikeforge#81 reference shape (several existing hooks are also over 120).
  • New model.build/model.built* strings are English-only with the standard EN fallback, matching the recent publish.* keys.
  • The pull Cancel button is wired to hub_cancel per the server's intent, but over a real socket the current server ignores pull-cancel: server/app.py intercepts hub_cancel before the pull-aware handler. Filed as hub_cancel over the socket never reaches the pull-aware handler spikeforge#96 with reproduction; no dashboard change needed once that lands.

Verification

  • npm run build — passes.
  • npm run scripts:test — passes, including 7 new unit tests for the error capture/unsupported classification (src/hubActionError.test.ts).
  • npm run desktop:test — passes.
  • End-to-end left to CI (this diff touches src/, so the selector takes the full tier).

Community entries gain a pull button streaming hub_pull_state progress
through the existing download-progress UI, and saved models gain a
build button in the bundle tab surfacing the built path/size/sha256.

Failures render the server's own error text. A pre-1.1 server answers
the unknown action type with a validation error, which reads as an
explicit unsupported-action note instead of a hang. Mirrors protocol
1.1 from spikeforge#81 (schemas + generated client).

Verified: npm run build, npm run scripts:test, npm run desktop:test.
End-to-end runs in CI.

Closes #47.
The panel now speaks protocol 1.1; the pins mirror the latest
compatibility.json row (spikeforge 0.6.0, hub/server 0.4.0) per the
file's own contract.
@w4ffl35
w4ffl35 merged commit bfd8115 into main Oct 14, 2026
5 checks passed
@w4ffl35
w4ffl35 deleted the feat/hubpanel-actions branch October 14, 2026 05:38
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.

HubPanel: expose pull and bundle-build actions

1 participant