You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Update modes on the server: automatic, pinned, approve first #755
First slice of #685. Build the data and service behind the signed update-flow mockup (sign-off page, card "ui-685", version 3, approved 2026-09-25).
One mode for every package: automatic, pinned (with a version), or approve first. It applies per package (admin) and per campaign (owner), for game-system packages and the Foundry module alike.
The Foundry module's existing settings map onto it.
A pin maps to pinned.
The stored preserve pin mode maps to pinned.
An empty mode or promote maps to automatic.
A package with auto-update off and no pin becomes pinned to its current version (approved default).
Approve first holds a newly installed version for that campaign until the owner or an admin approves it. An admin's "approve on their behalf" uses the existing force-pin action.
Game systems gain what Foundry pins already have:
a per-campaign version;
install-time auto-pin;
cleanup protection for any version a campaign is pinned to.
Cleanup stays as it is otherwise: game systems only, never Foundry module versions.
The auto-update check cadence (off, nightly, weekly, on release) stays the checking schedule under automatic and approve first.
No current function is lost. The mockup's "Everything today's screens do" list is the checklist.
Migrations are append-only and idempotent. Existing rows are carried over by an idempotent reconciler, not by a data migration.
Key Maker approved the updated screens (Sign-offs card mock-update-modes, version 1, 3 October) with plain labels: Automatic, Stay on a version, Ask me first (stored values can stay automatic / pinned / approve_first). Owners choose per package on Manage › Apps & game system (new Updates card); the Foundry setup guide links there; the admin Packages side panel Campaigns tab shows each campaign's choice and version with Move, Remind owner and Approve for them. Building the server slice first (no visible change), then the screens.
Done, not pushed: the per-campaign update work is built and reviewed. It includes the automatic old-version clean-up (packages migration 005), the server side for per-campaign updates (migration 006), and the approved "owners are asked" screens for the Foundry module (Update / Later on the campaign home, a row on Apps & game system with Use another version, and admin Hold / Move / Remind on Packages > Campaigns). The reviewer and migration-safety checks found no blocking issues.
Where it is: a git bundle in the project files (admin/admin-held-commits.bundle, head stack-held). It sits on top of Validate the pinned Foundry module version #976 and needs a rebase onto main before it can be opened as a PR.
Activity
keyxmakerx commentedon Oct 3, 2026
Key Maker approved the updated screens (Sign-offs card mock-update-modes, version 1, 3 October) with plain labels: Automatic, Stay on a version, Ask me first (stored values can stay automatic / pinned / approve_first). Owners choose per package on Manage › Apps & game system (new Updates card); the Foundry setup guide links there; the admin Packages side panel Campaigns tab shows each campaign's choice and version with Move, Remind owner and Approve for them. Building the server slice first (no visible change), then the screens.
Generated by Claude Code
keyxmakerx commentedon Oct 4, 2026
Paused for usage (operator request). State:
admin/admin-held-commits.bundle, headstack-held). It sits on top of Validate the pinned Foundry module version #976 and needs a rebase onto main before it can be opened as a PR.Generated by Claude Code