@getvitops/cli 2.0.0 → 3.0.0

package/CHANGELOG.md

@@ -1,5 +1,211 @@
 # @getvitops/cli
 
+## 3.0.0
+
+### Major Changes
+
+- 6e68ace: **Breaking:** the site config is now a three-section `Config` — `designSystem`,
+  `organization`, `site`.
+
+  The flat `SiteConfig` held the company (`organization`, `contact`, `locations`) and the
+  deployment (`analytics`, `environments`, `seo`, `legal`) as peers, so no single noun
+  described it, and a second site sharing the same company had no way to say so. The three
+  sections split those apart: several sites can now carry one `organization` and differ only
+  in `site`.
+
+  **Migrating.** `designSystem` stays at the root, and the fields already under
+  `organization` stay where they are. Everything else moves into one of two sections:
+  - → `site`: `defaultLocale`, `locales`, `domains`, `dns`, `cloudflare`, `environments`,
+    `abTesting`, `fonts`, `tags`, `postTypes`, `galleries`, `testimonials`, `templates`,
+    `navigation`, `seo`, `analytics`, `notifications`, `tracking`, `security`, `legal`,
+    `icons`, `favicon`, `deployment`
+  - → `organization`: `contact`, `primaryLocation`, `locations`, `services`, `links`
+
+  You do not have to work this out from the list: `vitops validate` detects a pre-3.0 flat
+  config and prints every move by name, rather than reporting a dozen unknown keys.
+
+  ```jsonc
+  {
+    "designSystem": {
+      "themes": {
+        "default": {
+          /* … */
+        },
+      },
+    },
+    "organization": {
+      "name": "Acme",
+      "contact": "hq",
+      "locations": {
+        "hq": {
+          /* … */
+        },
+      },
+    },
+    "site": {
+      "defaultLocale": "en",
+      "domains": {
+        /* … */
+      },
+      "analytics": {
+        /* … */
+      },
+    },
+  }
+  ```
+
+  **Renamed exports** (`@getvitops/generator`): `SiteConfigSchema` → `ConfigSchema`,
+  `SiteConfig` → `Config`, `validateSite` → `validateConfig`, `resolveSiteConfig` →
+  `resolveConfig`, `isSiteConfig` → `isConfig`, `siteJsonSchema` → `configJsonSchema`,
+  `SITE_SCHEMA_URL` → `CONFIG_SCHEMA_URL`, `SiteValidationResult` →
+  `ConfigValidationResult`. `ResolvedInput.site` is now `ResolvedInput.config`. New:
+  `OrganizationConfig` and `SiteSection` for the two sections.
+
+  **Renamed schema file:** `@getvitops/generator/site.schema.json` →
+  `@getvitops/generator/config.schema.json`. Update the `$schema` key in your config.
+
+  Option names are unchanged — `vitops({ site: { input } })`, the Vite plugin's `site`,
+  and `generate({ site })` still point at the config file.
+
+  **The Astro integration is now `vitops()`, not `getvitops()`.** It is a default export,
+  so the name is yours and nothing breaks on upgrade, but every example now reads
+  `import vitops from '@getvitops/astro'` — matching the Vite plugin, which has always been
+  `vitops`. The `@getvitops/*` package scope and the internal `virtual:getvitops/*` module
+  ids are unchanged; neither is an import name.
+
+  **Added:** a generated config authoring reference — `vitops docs config`, `docs/config.md`
+  in the OKF bundle, and _Config reference_ on the docs site. It is walked from the published
+  JSON Schema by the same helper that renders the `design-system.json` reference, so it
+  cannot describe a field validation does not accept.
+
+### Patch Changes
+
+- Updated dependencies [6e68ace]
+- Updated dependencies [b115993]
+  - @getvitops/generator@3.0.0
+  - @getvitops/utils@3.0.0
+
+## 2.1.0
+
+### Minor Changes
+
+- 20e518e: Add `vitops indexing` — tell search engines about a deploy, instead of opening Search Console by hand.
+
+  Configure it in your site config under `seo.indexing`, then run it after deploying:
+
+  ```jsonc
+  "seo": {
+    "indexing": {
+      "indexNow": { "key": "…" },
+      "searchConsole": { "siteUrl": "sc-domain:acme.ca" },
+      "priorityUrls": ["https://acme.ca/", "https://acme.ca/services"]
+    }
+  }
+  ```
+
+  ```
+  vitops indexing --dry     # print the plan, make no requests
+  vitops indexing           # submit
+  vitops indexing --check   # a day or two later: did Google actually index them?
+  ```
+
+  It reads your sitemap, diffs it against the previous run, and submits only what changed —
+  pinging **IndexNow** and re-submitting your sitemap through the **Search Console API**.
+  `--check` inspects `priorityUrls` and exits non-zero on a page Google hasn't indexed, so a
+  scheduled CI job can catch a page that quietly fell out of the index.
+
+  **Be clear-eyed about what this can do.** Google exposes no API that requests indexing — the
+  button in Search Console isn't available anywhere, URL Inspection is read-only, and the sitemap
+  ping endpoint was removed in 2023. IndexNow reaches Bing, Yandex, Naver, Seznam and Yep; Google
+  doesn't participate. So this automates every sanctioned step and then verifies the outcome; it
+  does not make Google re-index on demand, and nothing can. Google's Indexing API is deliberately
+  not wired: it's scoped to job postings and livestreams, and using it for ordinary pages violates
+  its terms.
+
+  Also new, and worth wiring at the same time — **`gitLastmod()` for real sitemap dates**:
+
+  ```js
+  import vitops, { gitLastmod } from '@getvitops/astro';
+  vitops({ sitemap: { serialize: await gitLastmod() } });
+  ```
+
+  `@astrojs/sitemap` emits no `<lastmod>` by default, which means a crawler is told your pages
+  exist but never that one changed — and it's what lets `vitops indexing` submit a handful of URLs instead
+  of all of them. `gitLastmod()` derives each date from the source file's last commit, and leaves a
+  page alone rather than guessing (dynamic routes, ambiguous slugs, shallow clones): an inaccurate
+  `lastmod` is worse than none, because Google stops trusting the field site-wide.
+
+  Requires `fetch-depth: 0` in CI — the default shallow clone has no history to read, and it warns
+  when that's the case.
+
+  **Credentials.** IndexNow's key is public by design (it's served at `/<key>.txt` as the ownership
+  proof), so it lives in your config, and the Astro integration writes the file into `public/` for
+  you — `vitops indexing --new-key` generates one, `--write-key <dir>` writes it for non-Astro stacks.
+  Search Console needs a service account in `VITOPS_GSC_SERVICE_ACCOUNT` or
+  `GOOGLE_APPLICATION_CREDENTIALS`, added as an owner of the property; it's never read from the
+  config file.
+
+  Persist `.vitops/` between runs (a CI cache) — that's the changed-URL state, and without it every
+  run submits everything.
+
+  An environment whose `robots` policy says `noindex` is refused outright, so pointing this at
+  staging can't publish it to a search engine.
+
+- 9bf975a: Add `vitops media` — encode raw video into web-ready outputs, instead of hand-rolling an ffmpeg
+  script per project.
+
+  Keep unprocessed video in a `raw/` directory and run:
+
+  ```
+  vitops media --raw raw --out src/assets/processed
+  ```
+
+  Each source becomes three files: **VP9/WebM**, an **H.264/MP4** fallback, and a **JPG poster**.
+  Import them like any other asset, so your bundler content-hashes them:
+
+  ```astro
+  ---
+  import hero from '../assets/processed/hero.webm';
+  import poster from '../assets/processed/hero.jpg';
+  ---
+  <video poster={poster.src} autoplay muted loop playsinline>
+    <source src={hero} type="video/webm" />
+  </video>
+  ```
+
+  In Astro it's an integration option — `vitops({ css, media: { raw: 'raw', out: 'src/assets/processed' } })`
+  — and it runs in the same pass that generates your CSS. `@getvitops/vite` gains a matching `media`
+  option, and `@getvitops/utils/media` exports `processMedia()` for anything else.
+
+  Defaults: capped at 1920px wide, CRF 32, audio dropped (the common case is a muted autoplay loop),
+  poster from frame 0. All of them are flags. `--dry` prints exactly what a run would do.
+
+  **Runs are cached**, on source content plus encode settings, in `.vitops/media-manifest.json` — a
+  24 MB clip that took 88 seconds the first time takes 0.14 seconds the second. A missing output
+  re-encodes; a corrupt manifest re-encodes everything. Neither ever reads as "already done", because
+  that failure is silent and no rebuild would fix it.
+
+  **Commit the outputs and the manifest.** A fresh CI clone has neither and would re-encode from
+  scratch; committing both means CI never needs ffmpeg. It also keeps your history clean — ffmpeg
+  output isn't byte-reproducible across versions, so a CI re-encode would rewrite every video on any
+  toolchain bump. Use `--force` when you mean to re-encode.
+
+  **`ffmpeg` is an external tool, not an npm dependency** — install it yourself (`brew install
+ffmpeg`, `apt install ffmpeg`, `winget install Gyan.FFmpeg`). The command fails without it rather
+  than skipping: a page referencing a video that was never encoded is broken, not degraded.
+
+  Two defaults worth knowing about. The MP4 exists because older iOS and the in-app webviews inside
+  social apps still don't decode VP9, and it's written with `+faststart` — without which a browser
+  downloads the whole file before showing frame one. And a poster taken from frame 0 is often black
+  on a clip that fades in; that's `--poster-time`, not a bug.
+
+### Patch Changes
+
+- Updated dependencies [20e518e]
+- Updated dependencies [9bf975a]
+  - @getvitops/generator@2.1.0
+  - @getvitops/utils@2.1.0
+
 ## 2.0.0
 
 ### Minor Changes

package/README.md

@@ -25,6 +25,8 @@ npx vitops generate --format bricks,css --out dist
 | `vitops favicon -i <svg\|png> -o <dir>`            | generate a favicon set from a source image      |
 | `vitops agents [-o AGENTS.md] [--docs-dir <dir>]`  | link the agent skill + AGENTS.md pointer        |
 | `vitops docs [topic] [--all]`                      | print live reference docs to stdout             |
+| `vitops indexing [--dry] [--check]`                | tell search engines about a deploy              |
+| `vitops media [--raw <dir>] [-o <dir>]`            | encode raw video to WebM + MP4 + poster         |
 
 Every `--input` takes a `design-system.json` **or** the larger site config that embeds one
 (`company.json` / `site.json`) — told apart by shape, so name the file whatever you like. Add
@@ -98,6 +100,51 @@ vitops generate --input design-system.json --format design --out .
 whenever your stylesheet goes somewhere other than the repo root. Regenerate it with your CSS; it's
 derived from the same config, so it can't drift from what the browser gets.
 
+## Video (`vitops media`)
+
+Keep unprocessed video in a `raw/` directory and encode it into web-ready outputs:
+
+```sh
+vitops media --raw raw --out src/assets/processed
+```
+
+Each source becomes three files — VP9/WebM, an H.264/MP4 fallback, and a JPG poster frame:
+
+```astro
+---
+import hero from '../assets/processed/hero.webm';
+import poster from '../assets/processed/hero.jpg';
+---
+<video poster={poster.src} autoplay muted loop playsinline>
+  <source src={hero} type="video/webm" />
+</video>
+```
+
+Outputs land under `src/` so your bundler content-hashes them and they can be served immutable,
+while the raw sources stay outside anything it scans.
+
+Defaults: capped at 1920px wide, CRF 32, audio dropped (the common case is a muted autoplay loop),
+poster taken from frame 0. Every one is a flag — `--max-width`, `--crf`, `--audio`,
+`--poster-time`, `--max-bitrate`, `--outputs`. `vitops media --dry` prints exactly what a run
+would do without encoding anything.
+
+**Needs `ffmpeg` on `PATH`.** It's an external tool, not an npm dependency — install it yourself
+(`brew install ffmpeg`, `apt install ffmpeg`, `winget install Gyan.FFmpeg`). The command fails
+rather than skipping: a page referencing a video that was never encoded is broken, not degraded.
+
+**Commit the outputs and `.vitops/media-manifest.json`.** Runs are cached on source content plus
+encode settings, so a second run costs a hash per file instead of minutes — but a fresh CI clone
+has neither, and would re-encode everything. Committing both means CI never needs ffmpeg at all.
+It also keeps your history clean: ffmpeg output isn't reproducible across versions, so a CI
+re-encode would rewrite every video on any toolchain bump. Use `--force` when you mean to
+re-encode, and commit the result.
+
+Two things worth knowing before you conclude something is broken:
+
+- **Frame 0 is often black** on a clip that fades in. That's `--poster-time`, not a bug.
+- **A missing output re-encodes, a corrupt manifest re-encodes everything.** Neither ever reads as
+  "already done" — the failure that would cause is silent, and a rebuild would never fix it.
+
 ## Teaching AI agents (`vitops agents` + `vitops docs`)
 
 This package **ships an agent skill** (`skill/SKILL.md`, the [Agent Skills](https://code.claude.com/docs/en/skills)