Skip to content

Refresh, runtime, and acceptance

Keep three boundaries distinct: generating a local candidate, publishing validated snapshots into an existing runtime, and starting or restarting the actual Glance service. The first two do not prove the external site changed.

Manual reads versus explicit scheduling

chatglance refresh projects --no-restart
chatglance refresh sites --no-restart
chatglance refresh --json-output --no-restart

refresh collects and publishes only managed pages already present in the Glance config and reports success/partial failure per page. It validates a candidate with the selected Glance binary's config:validate before backup and replacement; failed pages keep old files, with a shared nonblocking lock. --no-restart leaves the service running as-is. These commands are illustrative: missing runtime, credentials, or validator cause failure; they do not set up an environment for you.

Every native, scheduled, or browser attempt has one run_id; its safe journal lives under runtime private/refresh-history. Use chatglance runtime history list / show RUN_ID read-only. history prune previews by default and only --apply removes confirmed-owned, unprotected records. Typed defaults are 30 days and 256 MiB. Records contain no exception text, Token/Cookie values, configuration, or whole account snapshots.

Current server state is separate from the last successful observation. Offline stays offline; server_id is optional and otherwise derived from alias plus the reviewed target/user/port. When the complete identity matches, the native card retains marked historical CPU/memory/GPU/disk/system fields and shows last success plus this attempt. A new or changed identity says no history. Last-good and the visible snapshot share one validation/publication transaction; user notes are overlaid only while rendering.

Manual calls without --scheduled never redeem reset cards; account pages only display snapshots. Existing scheduling must use explicit --scheduled with per-account policy, not infer authority from a rendered toggle. When refreshing projects in optional-login mode, guest columns are rebuilt from the Public allowlist and authenticated columns retain full rows. A broken layout is rejected rather than overwritten with private guest content.

Fixed pages and read-only instance boundary

runtime instance init stores an explicit named ChatGlance profile, page allowlist and enabled subscription labels in private private/instance.json. The owner can change the definition with runtime instance configure --page ... --account ... --apply, disabling or re-enabling modules and accounts in that same profile. refresh --runtime-home <instance root> resolves native collector settings from that profile, calls only saved selected modules and rebuilds Go YAML from the instance's own snapshots. Execution-time CLI pages and --profiles cannot add content outside the manifest. Account JSON, resources and the page contain only the selected labels. Empty tracking or disabled labels fail without reviving old cached accounts. runtime serve verifies the YAML page, native server and login definitions again.

For a projects page, set its owner in the named profile or pass --projects-owner. Its GitHub token must also come from that profile; a missing token fails before ChatGH runs, without borrowing the main active profile, process or local Git credentials. Server and site inventories must belong to the instance runtime, not the main site.

Even refresh --scheduled cannot consume cards or write policy/ledger state for an instance. Cards keep the existing quota/calendar presentation but render no control entry. runtime controls, legacy account-limits control-serve and runtime maintain reject the instance. Native Go login reads the sensitive real password and independent 64-byte session key from exactly its named profile. The password travels through a private child-environment YAML scalar reference and Go hashes it internally. Existing hash-only templates remain compatible; missing fields for the selected template fail without active, main or process login fallback. The main runtime without an instance manifest keeps its previous behavior.

Multiple tracked accounts

Tracking is separate from credentials: named ChatEnv CRS profiles own the service Base URL and scoped management Key. ChatGlance's CHATGLANCE_ACCOUNT_LIMITS_SUBSCRIPTIONS stores explicit references only:

{"work":{"crs_profile":"reader-work","account_id":"account-01","enabled":true},"personal":{"crs_profile":"reader-personal","account_id":"account-02","enabled":true}}

Entries may use different profiles or CRS services; there is no two-account limit or automatic credential/account enumeration. Each Key must grant reads for its exact account. Newly monitored accounts should receive read-only scope, while upstream OAuth stays in CRS. Registering tracking never issues or rewrites a Key.

chatglance account-limits subscriptions list --json-output
chatglance account-limits subscriptions add work --crs-profile reader-work --account-id account-01 --execute
chatglance account-limits subscriptions disable work --execute
chatglance account-limits subscriptions enable work --execute
chatglance account-limits subscriptions remove work --execute
chatglance refresh account-limits --json-output

Omitting --execute previews the configuration change. subscriptions --env-profile dashboard-a edits that named ChatGlance profile without activation; --home selects an explicit ChatArch home. Tracking enablement does not enable card use: new policies stay off and old policies remain unchanged. Removal stops collection and stale-popup access but retains policy, ledger and the identity tombstone, without revoking potentially shared credentials. list --all includes removed references; a label cannot silently change account.

Unset registry configuration preserves legacy PROFILES, shared CRS_PROFILE and CRS_ACCOUNTS behavior. The first managed write migrates complete explicit legacy bindings. An explicit {}, all-disabled registry or all-removed registry means no active tracking, with no snapshot resurrection. Invalid batch structure fails before account/public-source requests or collector output. Individual provider failures remain truthful partial/error rows without local OAuth fallback or hiding healthy accounts. Collection, first migration, tracking writes and consuming controls share a per-ChatArch-home configuration owner, independent of runtime location; busy operations do not execute. A label with an orphan historical policy cannot bind a new account without a provable identity; choose a fresh label.

Page action feedback

Projects retain their original icon; servers retain the same original-position, labeled Refresh control and show Refreshing while work runs. If a click finds an existing run that truly includes that page, the control attaches to and tracks that exact run_id until it finishes, then reloads the parent data instead of recording a no-op busy click. A lock for an unrelated page remains an explicit busy result. Transient status-read failures do not falsely finish work or enable duplicates; the same tab resumes its own started or attached run after reload. Success shows Refresh completed with that invocation's real completion time; partial, failure and busy results remain truthful. Opening a page never spins for an unrelated scheduled run, and completion and observation times remain separate.

Subscriptions do not gain another header button. The account popup's original 刷新状态 (Refresh status) button reads only the selected account's latest quota, credits and conditions through its authenticated same-origin endpoint, without consuming credits or changing switches. The clicked button shows running; success updates Latest status refresh, rerenders the popup and leaves a success receipt; failure stops and preserves old data. Last scheduled check retains the actual scheduled snapshot time. The latest read-only row lives in a private per-account runtime cache, superseded by a later scheduled snapshot, without waiting behind full-site project collection.

Open a server's name to edit its note. Save, Cancel and Clear are explicit: a successful save or cancellation closes the popover, cancellation discards unsaved input, and Clear empties the input without deleting the persisted note until Save. Conflicts and save failures preserve the editor and input.

Manual check and use

After signing in, open the account control popup on the subscription page and choose 检查并用卡 (check and use a credit). Only after explicit confirmation does the server reload that account's current policy, live quota and available cards. It attempts at most one exact card only when the configured threshold and all existing time-window, forecast, identity and idempotency conditions pass. It does not wait for the next scheduled scan or weaken existing safeguards.

Cancelling, viewing, ordinary refreshes and native form submissions without JavaScript never redeem. The action reports success, unmet conditions or an uncertain result with its check time; the checklist above remains explicitly the last scheduled snapshot. Do not repeat an uncertain action before reconciling the ledger and quota. Production acceptance only views or cancels the confirmation; synthetic accounts and cards validate consumption.

Service boundary

Force one credit

The account popup's 强制用一张卡 (force one credit) skips automatic enablement, usage thresholds, remaining-time requirements, forecasts and business cooldowns. After separate confirmation, the server consumes at most one exact available credit for that account and reads back credits and usage without changing saved settings. Login, same-origin CSRF and duplicate protection still apply: in-flight or current uncertain operations block another consume, and timeouts never retry automatically. An expired old-window unknown record is archived only under force authorization, not relabelled as unconsumed. The management Key needs consume permission for the selected account.

  • projects update-config writes an explicit output path, not a deployment; a single-origin candidate cannot alias its inputs.
  • runtime maintain operates on an existing config and can validate, back up, or restart; confirm inputs, permissions, and backups before invoking it on any real runtime.
  • runtime render-systemd shows templates; runtime install-systemd and runtime start change user-level service/timer state. This documentation does not start them.
  • Server collection reads only explicit SSH aliases. Site cards use a reviewed inventory, not automatic domain discovery. server-stats shows only meaningful disk mounts.

Post-deployment functional and security acceptance

  1. At the same URL, read guest home and /projects; inspect navigation, content APIs, HTML/JSON/caches for zero Private identifiers, URLs, counts, or CLI/Env details; verify the exact legacy /项目 redirect.
  2. Sign in with an existing Glance account and inspect all Public/Private/Unknown rows at the same path. Direct visits to private pages and content APIs must be server-protected.
  3. Log out, reload, navigate back, and fetch again; private responses must not be recoverable from caches. Test mobile and desktop navigation manually.
  4. Identify the actual Glance executable with both public and authenticated-columns, and retain pre-upgrade config and rollback options. Do not mistake a static docs build for this evidence.

Docs deployment uses GitHub Actions: PR preview targets /dev/ and main deploys the root. Both require actual Pages configuration and external readback before anyone can claim publication.