# Site management Use for later edits, live-site reviews and recurring maintenance. Initial creation still follows the graph through verified local preview. Run `vitris manage prepare --site .`, then read `SITE-MANAGER.md` and `agent/site-manager/CONTEXT.md`. Read relevant source files through that index; do not load the whole agent kit. Honor `agent/overrides/refs/site-manager.md` when present. ## Understand and edit the site Check `launch.json`, `site.json`, accepted `agent/site-memory.json`, and the latest relevant release/review records. The context records a source revision and known integrations, not a guarantee that production matches local source. Inspect the current business facts, route sources, components, theme, media and relevant onboarding evidence for the task. Use `SITE-MANAGER.md` for goals, important journeys, service ownership and maintenance decisions. Keep it current as verified facts change; do not duplicate all page content there. Use the site's refinement workflow in `AGENTS.md`: classify the change, capture its baseline, preserve accepted preferences and verify the affected behavior. Read `refine.md` for a classified refinement; preservation sites follow their preservation instructions and edit `preserved/`. Prepare justified routine fixes locally and report the findings, changed files, verification and remaining decisions. Do not publish from a recurring review without a separate publication instruction. A publish-only request keeps the existing quick-publish contract; management does not add a launch gate. ## Check harness releases and compatibility Include update discovery in every recurring review and before a requested harness upgrade. Read the website's `package.json`, lockfile, installed package metadata, `agent/managed-files.json`, overrides and release receipts. If a separate admin is configured, locate its actual repository through the handbook and connection records; inspect its own package/lockfile, installed metadata, `admin.config.json` and deployment evidence. The website harness's admin installer dependency does not establish the separate admin's installed or deployed version. If no admin exists, record it as not installed; do not provision one as maintenance. Check the public npm registry for published website harness, admin harness and associated admin contracts releases. For example, use `npm view @tryvitris/website-harness dist-tags versions time --json`, and the equivalent query for `@tryvitris/website-admin-harness` and `@tryvitris/website-admin-contracts`. Read the publisher's release notes and versioned upgrade instructions for candidate versions. Record the source and check time; unavailable registry or release evidence means update availability is unknown. Respect the site's selected release channel; do not select a prerelease or downgrade merely because a tag points to it. Report declared, locked, installed, managed-kit and known deployed versions separately, with available and recommended versions and the reason for the recommendation. Flag unexplained differences, local/file dependencies that cannot be matched to a published version, stale copied instructions and conflicting overrides for investigation. An intentionally pinned or older compatible release is not automatically a defect. Choose a compatible set based on the website compiler/runtime, admin contracts, actual deployed backend API and schemas, booking/forms/authentication capabilities and release-specific migration requirements. A shared major version or successful local install is not compatibility evidence; unknown deployed versions remain unknown. For a recommended update, prepare the exact-version dependency/lockfile diff locally and follow `docs/DISTRIBUTION.md` plus the installed package's upgrade instructions. Run `vitris upgrade --site SITE --plan` before managed-kit `--apply`; that operation updates instructions, not npm dependencies. Inspect conflicts and preserve authored source, overrides, launch configuration, accepted memory and workflow progress. Read `admin.md` and `docs/ADMIN.md` for admin changes; use the published version-specific workflow and inspect the package/UI/schema diff. Record required checks and rollback to the previous verified source, lockfile and release. Backend migrations, shared service changes, publication and deployment remain separate operations with their existing authorization requirements. ## Detect anomalies and keep changes consistent Compare current observations with prior dated reports, accepted source and production receipts. Look for unexplained route/content changes, broken interactions, asset or runtime errors, unexpected tracking, dependency/configuration drift and divergence between local and deployed behavior. For analytics, examine unusual changes in traffic, engagement, accepted conversions and field performance against comparable production periods and owner goals. Record the affected routes or services, evidence, timing, scope and possible recent changes. Separate a confirmed fault from a suspected regression, expected seasonality, low-volume noise or missing access; do not invent a causal link to an update. Before **every** proposed change, establish the site's accepted conventions from its design system, theme tokens, shared components, route/layout patterns, business facts and current site memory. Assess package, content, component, configuration and admin updates against that baseline. Preserve the established typography roles, color/spacing tokens, responsive navigation and layout behavior, motion/accessibility preferences, form and booking contracts, consent/tracking behavior and build/deployment path. Reuse existing shared patterns and correct the shared cause when appropriate instead of adding a competing implementation on one page. Keep intentional page differences and documented exceptions; consistency does not require identical pages or identical public-site and admin layouts. Admin branding should continue to use the supported website theme handoff. For cross-cutting changes, enumerate affected routes, components and integrations; check the shared behavior across them, including desktop/mobile and relevant reduced-motion or no-script states. Preservation sites retain their captured appearance and interaction contract. Run impact-based build, browser, accessibility, performance and API/schema checks as applicable, and review the result against the accepted design before calling the local candidate ready. Keep unverified checks visible. Return anomalies, release findings, compatibility decisions, the coherence assessment, locally prepared changes and remaining decisions in the dated report. Update the handbook's system baseline only after the applicable verification passes; retain the prior baseline and evidence. ## Review the live site Verify the configured production origin is the intended site. A source URL, preview URL, deployment receipt or configured origin alone is not current uptime evidence. Check representative pages and the important desktop/mobile journeys, navigation and asset failures; inspect content freshness, accessibility and performance when relevant. Review forms, booking and admin using their own references (`contact-forms.md`, `scheduling.md`, `admin.md`); no real enquiries, bookings or customer notifications as synthetic tests. Private management routes must remain free of analytics and third-party scripts. Read `analytics.md` for the harness's built-in tracking. Use connected, authorized analytics and logs when available. Compare equivalent production periods and record dates, timezone, filters, sample sizes and sources; distinguish traffic, engagement and accepted lead conversions. Consider owner goals, seasonality and low volume. Beacon configuration is not proof of collection. Missing access/data is **unknown**, never a healthy result or zero traffic. Do not expose raw customer records or create a second analytics SDK to fill an access gap. Keep dated evidence and reports under ignored `artifacts/site-manager/`. Report verified failures, recommendations, locally prepared fixes, unverified areas and required owner decisions. Separate observations from hypotheses. Preserve previous reports so recurring reviews can detect change; leave accepted memory and workflow progress untouched until the applicable edit checks pass. ## Recurring reviews At the first verified production launch, prepare the review brief automatically and offer scheduling setup as part of the handoff. If the owner has already requested recurring reviews and supplied the needed cadence/timezone, proceed with setup through the current agent's available scheduler. Otherwise resolve only those missing preferences. There is no implicit cadence or active schedule merely because files exist. Use `agent/site-manager/review-task.md` as the task prompt, bound to this website repository, with the user's cadence/timezone. Inspect existing tasks before creating one; reuse or update the matching task. In Codex use the available native automation tools. In another agent inspect its actual scheduling capabilities; when no scheduler exists, offer an explicitly configured external runner instead of claiming the agent will wake itself. Never install an active CI workflow or recurring OS task as a side effect of site creation or upgrade. Record cadence/timezone preferences in `site-manager.json`. Store the confirmed provider/task ID in ignored `agent/site-manager/schedule.json` only after setup succeeds; local account configuration stays out of Git. This reference does not prove the external task remains active. Verify task state in the scheduler when asked. A scheduled environment must have the repository, network and authorized read access to the required sources; missing access belongs in the report. Run a manual review before enabling unattended reviews, using the same access restrictions. Report findings and prepare fixes locally; production deployment and shared-backend changes require their own instructions.