The update console stops being a page of its own and becomes the last section
of 系统设置 (data-section="update", gated by update:read): the sidebar entry
and page-system-update are gone, the console markup lives in
settings-section-update, and the settings menu is where an operator now finds
it. #system-update keeps working as an alias - both hash parsers normalize it
to settings + the update section - so existing deep links and docs keep landing.
Polling follows the new home: leaving the settings page (router) or switching
to another section (settings.js) stops it, selecting the section loads the
console, and returning to the settings page with the section still selected
re-reads the install tree and re-arms the poller (a frozen progress read is
the "nothing is happening" picture an operator must never be shown).
The guard suite follows the move: the old nav/page assertions become "must not
exist", the new ones pin the section, the alias, the poller handoff and the
retired nav.systemUpdate key (settings.nav.update replaces it in zh/EN/RU).
README and both developer/deployment guides say 系统设置 → 一键更新.
The console page grows an update-source section: what is in effect and where it
comes from (config.yaml or the tree's own tracking), an edit form for the three
fields, and - for a directory that is not a git installation - the adopt entry.
Adopt is preview-first: the plan lists what would be replaced and what would be
kept, the confirm dialog carries the counts, and the restart tick is the same one
an update uses. A refused save shows the server's own sentence (a remote name and
an address together, an ext:: address) instead of a generic failure, and the typed
values survive the failed save and the polling redraws.
zh/EN/RU dictionaries carry the 27 new keys; the console page's contract tests
grow to 29 (source rendering and save body, the refusal path, adopt gating by
installation kind, preview-then-confirm); docs/README describe choosing a source
and connecting an unpacked installation.
An operator running a fork has no honest way to upgrade: upgrade.sh downloads the
Release tarball of one hard-coded third-party repository and rsyncs it over the
tree, so "upgrade" means "overwrite yourself with somebody else's code", and the
safe alternative is to pull by hand and remember the build command.
internal/update drives the remote the directory already tracks: fetch, fast-forward,
go build into .update-staging, atomic rename of the binary (the previous one kept as
cyberstrike-ai.prev), and a .update-state.json so a rollback has a target that is
not guessed at. Refusals are the point - local source edits and a diverged branch
stop with the file names and commit counts in the error rather than being reset to
match, and operator-owned content (roles/skills/tools/agents/data/config.yaml) is put
aside before the merge and restored over it, with what was kept listed in keptContent
instead of quietly dropped.
Consumers: GET/POST /api/system/update* behind update:read / update:apply (mutations
are process-global, so they need a global-scope session); a console page at
#system-update with an apply button that names why it is blocked, a job polled from
the server and a rollback control; the same three actions as -check-update / -update
/ -update-rollback on the binary; OpenAPI entries for all five endpoints. Permission
gating no longer re-enables a control a page disabled for a reason of its own
(data-state-disabled), which every state-disabled, permission-gated button in the
console was subject to. upgrade.sh becomes a thin shell over the same implementation
and only falls back to the tarball path for installs that are not git work trees.
Docs and the zh/EN/RU dictionaries are updated. The package runs 13 tests against
real temporary git repositories; the HTTP layer, RBAC and the console page each
carry their own contract tests.
Runtime artifacts (agent workspaces, tool-output spill, C2 payloads, chat
uploads, workflow checkpoints, diagnostic logs) previously accumulated
without bound: most were only removed when a conversation or project was
deleted, and tmp/c2 plus workflow checkpoints were never removed at all.
Add a storage cleaner with named per-category tasks (Gitea-style), a
settings page tab, and a background sweep that is off by default so
upgrading never deletes existing data.
Safety properties, since mis-deleting live task data costs far more than
the disk saved:
- dry-run is the default; a real cleanup requires dry_run=false together
with confirm=true at the API layer, not just a frontend dialog
- sessions active within active_grace_hours are always skipped, and a
failed activity lookup skips conservatively (fail closed)
- directories whose conversation/project no longer exists are reclaimed
as orphans after orphan_grace_days
- scanners never follow symlinks and every candidate path is confined to
its category root; deletion renames to a .tmp-for-deletion marker first
so a crash leaves recoverable residue instead of a half-deleted dir
- storage:* permissions are admin-only; without the grantSystemRolePermissions
skip the default branch would have given operators an irreversible
file-deletion right
Also fix two confirmed leaks: DeleteConversation left chat_uploads files
on disk (their rows already vanished via ON DELETE CASCADE), and workflow
checkpoints had no deletion path at all.
Co-authored-by: Parallels <parallels@kali-linux-2025-2.localdomain>
Let audit_agent approve or reject with one System One call instead of chat JSON, while keeping the OpenAI-compatible backend as an option.
Co-authored-by: Cursor <cursoragent@cursor.com>
Sycun