# One daily site-care task

Use this reference for requested recurring care and scheduled runs. Site creation/upgrade/publication prepares management files without activating a schedule. Honor previously supplied owner preferences and authorization. Keep one daily task per site; its coordinator assigns weekly and monthly checks when due. Default proposed time is 09:00; resolve the site's timezone before setup. Weekly periods start Monday in that timezone; monthly periods start on the first. The first run covers all three scopes. Missed work is due at the next run, without replaying every missed day. Calendar periods handle daylight saving; a repeated daily trigger is harmless.

## Set up through the current agent

1. Refresh with `vitris manage prepare --site .`. Inspect the current agent's actual native scheduler tools and existing tasks. Prefer persistent cloud execution that can access the committed repository, skill, network, dependencies and authorized sources while the computer is off. Do not infer cloud support from an agent's brand. Codex tool surfaces may expose only local execution; Claude's cloud scheduled tasks depend on account/org/tool availability. Session-only loops are not a durable fallback. If no durable scheduler is available, report setup needed.
2. Select state before configuring: a fresh cloud checkout needs the dedicated remote state service below. File state is for a canonical local directory only. If native cloud scheduling/environment/remote state is unavailable, select a persistent local scheduler and explicitly explain that the computer and agent must stay on. Do not silently move an existing remote state to local files or create a second job. Changing state providers later requires a separately reviewed migration preserving history and leases.
3. Configure preferences: `vitris manage care configure --site . --timezone America/New_York --time 09:00 --state remote --json` (or `--state local` for fallback). The generated care site ID is stable and tracked in `site-manager.json`; preserve it across branches/upgrades. Legacy cadence and task references are preserved until this explicit opt-in. Cadence becomes daily; report-and-prepare-fixes policy is retained. A copied website for a different business must be initialized as a new site, not share this ID/service.
4. Save an ignored capabilities file, e.g. `agent/site-manager/capabilities.json`, describing observed native tool availability. Example: `{"provider":"current-agent","cloud":{"available":true,"evidence":"actual native tool names and inspected execution schema","repository":"https://github.com/OWNER/SITE","environmentReady":true},"local":{"available":true,"evidence":"actual persistent local tool names"}}`. Set unavailable modes to false/omit them. Environment-ready means cloud credentials/network and retained task artifacts are actually configured. Run `vitris manage schedule plan --site . --capabilities agent/site-manager/capabilities.json --json`. It writes an ignored `agent/site-manager/schedule-plan.json`; inspect its selected execution, binding, reason and prompt. Use this plan, not invented provider APIs. Local execution binds the canonical directory, without per-run worktrees. A scheduler that cannot honor the site's timezone, daily time or this binding is unavailable for this plan.
5. Run a manual review through `care begin`/`complete` using the same state/access as the intended task. Complete all three scopes at least once; keep its run ID. Missing analytics can be a documented unverified area of a completed review; if a scope cannot actually be reviewed, mark it blocked rather than claiming completion. Cloud setup must also verify a real manual native cloud execution can use the repository/state and retain its report/patch artifacts before enabling unattended runs. Remote credentials must be in the cloud environment, not only the interactive terminal.
6. Through native tools, reuse/update the matching task or create exactly one daily task from the plan. Read it back: correct site binding, prompt, one daily schedule in the selected timezone/time, selected execution environment, active status, appropriate model and available access. Do not install active CI/OS jobs as a scaffolding side effect. If a task already exists on another scheduler, migrate or disable that task through its tools before enabling a replacement. Task inspection must cover the site's known scheduler references; a busy coordinator prevents overlap but does not replace deduplication. Configure delivery preferences using the provider's supported settings; surface meaningful changes/failures and weekly/monthly summaries where supported.
7. Save the read-back as ignored `agent/site-manager/schedule-receipt.json`: `{"planId":"FROM_PLAN","siteId":"FROM_PLAN","provider":"FROM_PLAN","taskId":"REAL_ID","executionEnvironment":"cloud","binding":"FROM_PLAN","cadence":"daily","time":"09:00","timezone":"America/New_York","active":true,"matchingTaskIds":["REAL_ID"],"verifiedAt":"CURRENT_ISO_TIME","manualRunId":"COMPLETED_MANUAL_RUN"}`. These fields attest native observations; the CLI does not call the scheduler. Run `vitris manage schedule record --site . --receipt agent/site-manager/schedule-receipt.json --json` within 15 minutes of read-back. It checks the current plan/settings, single task binding and initial all-scope completion and a recent successful manual run of assigned scopes, then saves `agent/site-manager/schedule.json`. Report the actual provider, task, execution mode and any fallback limitation. Files are a last-verified receipt; check the external scheduler to establish current activity. If setup fails after task creation, inspect and pause/remove the incomplete task through native tools rather than leave an unreported active job.

## Coordinator protocol

Run `vitris manage care begin --site . --json`. `started` returns `packetFile`, assigned `scopes`, local calendar `periods`, expiry, previous open findings and comparison baselines. `busy` or `already-completed` ends the run. Run only assigned scopes using `agent/site-manager/review-task.md`. Preserve that run's unique packet file; do not substitute another run's packet. The packet contains a lease token and is ignored. The CLI saves its identity before contacting state; if the response is lost, retry `begin --packet SAVED_RUN_FILE` with the same identity. Do not create new identities in a retry loop.

The one-hour lease uses the service clock for remote state. Renew at least every 20 minutes: `vitris manage care renew --site . --packet PACKET --json`. A superseded or expired lease cannot renew/complete. On renewal/state failure, stop repairs and report the failure; never start independent local state. Save a redacted structured report in `artifacts/site-manager/RUN-report.json`:

```json
{
  "scopes": { "daily": "completed", "weekly": "completed", "monthly": "blocked" },
  "findings": [{ "key": "availability:home", "scope": "daily", "severity": "critical", "summary": "Production home route returned 503 twice.", "evidence": ["https://example.com/", "2026-11-06T14:00:00Z"] }],
  "baselines": { "daily": [{ "summary": "Home HTTP 503; analytics unavailable (no authorized access).", "source": "Production HTTP observations", "period": "2026-11-06 America/New_York" }] }
}
```

Include exactly assigned scopes with `completed|blocked|failed` outcomes; findings may belong only to those scopes. Completion means the review executed, not that the site is healthy. Failed/blocked scopes stay due. Keep stable finding keys and scope ownership across runs; include every still-open finding of completed scopes. Omitted findings resolve only in completed scopes. Findings in blocked scopes retain prior history. Compare sources and equivalent production windows before alleging an anomaly. Baselines are optional bounded, non-sensitive observations for completed scopes, retained unless explicitly replaced (use an empty array to clear a scope). Include dates/timezone, filters/sample sizes in analytics summaries and reference redacted durable reports. Missing access is unknown; no credentials, raw customer records or private/signed URLs in state. Limits: 50 open findings, four evidence strings each; 12 baselines per scope. Consolidate related issues when necessary.

Complete before expiry: `vitris manage care complete --site . --packet PACKET --report REPORT --json`. Save/retain the receipt with the report. Exact completion retries are idempotent within the most recent 16 completed runs; a different report for that run is rejected. The receipt reports opened/changed/resolved/ongoing keys, new/changed critical keys, and whether weekly/monthly digest work completed. Ongoing findings do not count as new merely because evidence timestamps changed. Cross-period runs advance only the periods assigned at begin; newly due periods wait for the next invocation. If unable to review, `vitris manage care abort --site . --packet PACKET --json` releases the lease without advancing any scope. A crashed task's lease expires for the next run.

`vitris manage care status --site . --json` reads last completion per scope, baselines, open findings, recent receipts and the lease expiry; it does not check website health or scheduler activity. It contains no lease or service token. Local state and run packets are ignored under `agent/site-manager/care/`. Cloud state persists only bounded summaries/receipts; retain detailed reports and reviewable patches in native cloud task artifacts before checkout disposal. Do not automatically push branches or publish fixes. No service/backend provisioning, production publishing or customer messaging belongs in a review.

## Optional dedicated cloud state service

The package ships `bin/cloudflare/site-care.js` and `cloudflare/site-care/wrangler.example.jsonc`: a small bearer-authenticated Worker with a separate SQLite Durable Object. It performs each begin/renew/complete/abort transaction atomically and supplies the authoritative clock. This service stores state; the native agent scheduler runs reviews. It has no cron trigger and no access to the business backend. Provision/deploy it only as an explicitly authorized dedicated service in the owner's account; never merge bindings/migrations into an existing shared backend or deploy anything during `manage prepare`/upgrade.

Copy the example into the site's ignored operator configuration at `cloudflare/site-care/wrangler.jsonc` (add this real config to `.gitignore`; commit only a placeholder example if desired). Its relative main path assumes this two-level directory inside the site; adjust to the installed package if stored elsewhere. Set a dedicated unique Worker name/account, `SITE_CARE_SITE_ID` from configured `site-manager.json`, and keep the example's new SQLite class/migration on this new service only. Create a random token of at least 32 characters using a password manager or cryptographic generator; set it with `wrangler secret put SITE_CARE_STATE_TOKEN --config cloudflare/site-care/wrangler.jsonc`, then explicitly deploy the dedicated Worker. Never put the token in JSON, shell history arguments or Git. Bind the same credentials in the native cloud environment's secret store:

- `VITRIS_SITE_CARE_STATE_URL=https://DEDICATED-WORKER/v1/care`
- `VITRIS_SITE_CARE_STATE_TOKEN` (same dedicated bearer secret)

The endpoint allows server-to-server POST only, rejects browser Origin requests, authenticates before state access and checks the site ID. HTTPS is required except loopback development. No credentials in URLs or redirects. Back up/migrate the dedicated durable state before replacing its binding/name/site ID. Rotate secrets through the owner account and update scheduled environments together. A remote outage fails closed without local state fallback. Local fallback is a setup choice when cloud prerequisites are unavailable, with the same coordinator/file persistence in the canonical local repository. Later migration to cloud must preserve history and exclude simultaneous writers.

Provider references: [Codex scheduled tasks](https://learn.chatgpt.com/docs/automations), [Claude cloud scheduled tasks](https://code.claude.com/docs/en/routines), [Claude scheduled-task modes](https://code.claude.com/docs/en/scheduled-tasks), [Cloudflare SQLite durable storage](https://developers.cloudflare.com/durable-objects/api/sqlite-storage-api/). Actual native tools and account availability decide the supported execution mode.

## Daily package maintenance

Each assigned daily review runs `vitris manage updates --site . --out agent/site-manager/package-updates.json --json` and follows `agent/refs/package-updates.md`. Prepare/test compatible candidates; preserve current publication permissions. Use the existing task, coordinator lease and stable findings. Partial release publication, registry outages, missing separate-admin access and deployed-version evidence stay unverified. Package installation and files do not activate a new scheduler.