# Daily package updates

Use `vitris manage updates --site . --out agent/site-manager/package-updates.json --json` during assigned daily care and before publication. This command checks the public npm stable releases, compares actual declarations/lockfiles/installed packages and returns pinned preparation plans. It does not install, deploy, migrate, rotate keys or activate a scheduler. Network failures and missing evidence are unknown.

For a separate admin, bind its existing source once with `vitris manage updates --site . --admin-dir ../EXISTING_ADMIN --bind --json`. The admin manifest must match the website's recorded installation/site/admin origin, public website origin and tenant when recorded. The command preserves other `site-manager.json` fields. Each run revalidates that binding. An unavailable cloud sibling checkout stays unverified; the website's installer dependency is never a substitute for the actual admin. Do not bind another business or expose a local path as a remote delivery address.

Follow the actual admin's packaged `agent/refs/package-updates.md`. New admin scaffolds include `npm run updates:check`; existing admins can use `vitris-admin updates setup --dir . --plan` and then `--apply` to add the check script/instruction block while preserving authored instructions. The runtime's Node maintenance SDK is shared by the website command so all three admin package identities, stable family and integrity rules agree.

When a compatible candidate exists, review release notes/engine requirements and compare current files to the returned baseline before editing. Prepare exact dependency versions with lifecycle scripts disabled; verify lockfile integrity against the recorded release before executing updated code. Use `vitris upgrade --site . --plan` and its reviewed apply workflow for managed website files. Refresh separate admin assets/instructions through its existing build and provenance workflow. Stop for drift, unknown/local source overrides, partial admin publication, breaking changes, custom adapters or overlapping owner edits. Hold optional migrations/permission changes for their own reviewed authorization.

Run local tests and the site's existing verification gates. Preserve authored content/design, custom modules, manifests, accounts, verifiers, reporting, SSO, billing, secrets and resource bindings. Keep previous package/lockfiles and rollout evidence. Follow existing publication permissions; a new package or release note grants none. Default daily care prepares a tested candidate for review. Retain cloud candidates as provider artifacts and renew the existing care lease while testing.

Reuse the current daily task and coordinator. Release publication refreshes the public package directory/documentation; the daily agent polls the canonical npm registry. Repository files cannot wake a suspended agent, activate a task or prove a deployed version. Do not add a second schedule. Existing tasks that refresh `vitris manage prepare` and read the generated review brief adopt this step after the site's one-time package/managed-kit upgrade. Inspect scheduler state with its native tools if actual enrollment is requested.

Record stable daily finding keys per package/candidate version, installed/locked/latest values, checked dates and tests. Keep ongoing updates ongoing instead of issuing duplicate daily alerts. Existing care begin/renew/complete and weekly/monthly work stay unchanged. No credentials, raw customer data or private URLs belong in reports or durable care state.