Website product config

config.json is the release-volatile source of truth for the Scanly marketing site (scanly-web).

Update this file when you ship a new app version. You should not need to redesign or redeploy the website for ordinary product updates.

What belongs here

Field	Purpose
`release.stableVersion`	Version badge on Download CTAs (e.g. `v1.0.16`)
`release.developmentLabel` / `developmentUrl`	Link for “what's new” / changelog
`release.releasesUrl`	Optional override for the Download CTA URL (Google Play preferred)
`screenshots`	Product-tour titles, bodies, and image paths or absolute URLs
`features`	Capability cards shown on the site (optional full replace)
`development`	Highlights for work shipping or in progress
`roadmap`	Soft future list
`openSource.stats` / `stack`	Optional open-source panel numbers and stack chips

Evergreen marketing copy (hero story, privacy pillars, workflow steps, navigation chrome) lives in scanly-web and is merged with this file at runtime.

Screenshot URLs

imageUrl may be either:

Repo-relative path (preferred): screenshots/mobile/image-1.jpeg
Resolved by the website to:
https://raw.githubusercontent.com/c1ph3rj/Scanly/<ref>/screenshots/mobile/image-1.jpeg
Absolute HTTPS URL to a hosted image.

Always set fallbackAsset to one of home | scan | pages | export so the site can fall back to bundled marketing images if the remote file fails.

Website ref

The website defaults to branch master for app docs and this config (override with VITE_SCANLY_GITHUB_REF).

Schema

schemaVersion must be 1
Text must not contain HTML markup (< / >)
URLs must be https:// or relative repo paths for images
Keep arrays within the limits enforced by the website validator

Checklist per release

Bump release.stableVersion to the public tag.
Update screenshot paths/titles if assets changed under screenshots/.
Adjust features only when user-facing capabilities change.
Commit on the release branch; the website picks it up without a content redesign.

AI agents

When asked to update docs or this config, ask the user first:

What's landing next?
What must be documented / put in config?
What is the required scope for this pass?

Do not invent development highlights or docs content without those answers. See root AGENTS.md.