Backup Coverage Auditor

Scans every Appwrite project you've authorized and reports which ones have an active backup policy, which have coverage gaps, and how recent the last restore point actually is — an account-wide view Appwrite's own Console doesn't show (it's one project at a time there).

Reuses the auth + OAuth2 console flow proven working in Permission Auditor, Environment Drift Detector, and Function Cost Estimator (same client-registration mechanism, same generic-domain endpoints — see src/auth/config.js; the "hardcode a region subdomain" instruction has now been independently disproven three times across three separate build specs, don't reintroduce it).

Every scope used in the three prior tools in this series turned out to work once the auth layer was set up correctly. This one is different — backups.policies.read, archives.read, and restorations.read are a new namespace nothing before this has exercised.

What's confirmed: all four scopes (project:backups.policies.read, project:archives.read, project:restorations.read, organization:projects.read) are listed in the console OAuth server's own discovery doc (scopes_supported) — confirmed by direct curl on 2026-07-05.

What's NOT confirmed:

1. Whether the consent screen actually lists these as grantable permissions.
2. Whether a granted token can call these endpoints without a role: guests-style error.
3. The endpoint paths themselves. src/api/appwrite.js's fetchBackupPolicies() / fetchArchives() / fetchRestorations() guess /backups/policies, /backups/archives, /backups/restorations off each project's own endpoint — these follow Appwrite's general REST convention seen elsewhere but have never been called with a real token.
4. The response field names. src/lib/scan-coverage.js guesses policies/archives/ restorations as the list keys (falling back to data) — unconfirmed.
5. The 48-hour staleness threshold in src/lib/coverage.js is a flat default from the build spec, not confirmed against Appwrite's actual policy scheduling granularity. Once real policy data is visible, check whether it exposes a schedule/interval field and prefer "older than what this project's own policy promises" over the flat constant.

What's fully verified and doesn't need re-checking:

• The coverage-assessment logic (src/lib/coverage.js) — unit-tested against fixtures covering no-policy, disabled-policy, policy-with-no-archives, stale, fresh, and unsorted-archive-order cases (see coverage.test.js).
• Auth, OAuth client registration, and the all-projects crawl pattern — identical to Permission Auditor, which works end-to-end.

To finish validating: log in with a real account, ideally against one project with an actual backup policy configured (set one up in Console if none exists) and one without. If any of the three fetchers throw, check the browser console for the actual error and HTTP status first — a 404 means wrong path, a role: guests/403 means the scope isn't actually granted despite being in scopes_supported. Report back precisely what you tried and what came back, same as the escalation pattern used for the earlier tools in this series.

npm install
npm test   # coverage.js unit tests, no auth needed
npm run dev