@getvitops/cli 4.0.0 → 4.1.0

package/CHANGELOG.md

@@ -1,5 +1,155 @@
 # @getvitops/cli
 
+## 4.1.0
+
+### Minor Changes
+
+- 2c890c0: Link a site to its ad properties: `site.ads`, `vitops ads`, and `<Ads />`.
+
+  `vitops search` covers the whole Search Console relationship. Nothing covered the equivalent one
+  with ad platforms, and a site's ad accounts had nowhere to live — so a Meta pixel pasted into a
+  template was invisible to the rest of the toolchain. It set `_fbp` on a site whose generated cookie
+  notice never mentioned it, whose consent gate never cleared it on revoke, and — for LinkedIn and
+  Pinterest — whose attribution never captured the click ID at all, so every conversion from those
+  platforms arrived indistinguishable from organic traffic.
+
+  **New `site.ads` block**, keyed by platform (`google`, `meta`, `linkedin`, `reddit`, `tiktok`,
+  `microsoft`, `pinterest`, `snapchat`):
+
+  ```jsonc
+  {
+    "site": {
+      "ads": {
+        "meta": { "pixelId": "123456789", "domainVerification": "abc123" },
+        "google": {
+          "accountId": "123-456-7890",
+          "pixelId": "AW-987654321",
+          "conversionLabel": "xyz",
+        },
+      },
+    },
+  }
+  ```
+
+  **`vitops ads setup`** ensures each platform's domain-verification DNS record. Only four platforms
+  verify a domain at all — Meta, TikTok, Pinterest and Snapchat, by apex DNS TXT — and that record is
+  the one thing created for you (in Cloudflare, via `CLOUDFLARE_API_TOKEN`; created only, never edited
+  or deleted). Google Ads, LinkedIn, Reddit and Microsoft Ads have no domain verification: linking
+  there is the tag and the account id, and the run says so rather than skipping in silence. No
+  platform Marketing API is called — Meta's needs a system-user token and Google's an approved
+  developer token with your own account on the line — so the final "Verify" click is surfaced as a
+  reminder. `--dry` prints the plan, `--check` reports drift and exits non-zero.
+
+  **It asks for what the config is missing.** A verification token does not exist until someone
+  fetches it from the platform UI, so a first run prompts for it, naming the exact UI path, folds the
+  answer into the plan and writes it to your config. The token is not a secret — it is published in
+  DNS, and the platform fetching it back is the ownership proof, exactly like the IndexNow key.
+  Prompting requires a TTY: with `--dry`, `--check`, `--no-prompt`, or in CI, you get a named error
+  instead and the run never hangs. `--no-write` keeps the answer out of the config.
+
+  **`vitops ads tags`** prints each pixel as an inert, consent-gated `<script>` — `type="text/plain"`
+  with the library URL on `data-src`, so an undecided visitor's page issues no third-party request.
+  For Bricks, WordPress, Eleventy: any stack without the Astro integration.
+
+  **`vitops ads lint`** reports the gaps that are invisible at runtime: a click ID the platform stamps
+  that attribution does not capture, a pixel while `site.tracking` is off, a property with no tag id.
+
+  **`<Ads />` in `@getvitops/astro`**, a sibling of `<Analytics />` rather than part of it — ad
+  properties come from the site config, state their own consent category (`marketing` by default,
+  rather than being derived), and switch per environment on their own
+  (`environments.<env>.ads`, defaulting to `analytics`, then true, so a preview deployment can send
+  pageviews without firing conversion pixels). Both components now render through one `<GatedTags />`,
+  so the inert markup has a single implementation.
+
+  **Your cookie notice now discloses every configured pixel** — name, cookies and opt-out — from the
+  same table that writes `data-consent-cookies`, so the notice and the revoke cannot disagree. If you
+  add `site.ads` to a config whose privacy policy or cookie notice you have already published,
+  re-generate and re-read them.
+
+  `li_fat_id` (LinkedIn) and `epik` (Pinterest) join the click-ID capture vocabulary; a site running
+  either platform starts attributing conversions it previously recorded as organic.
+
+- e764090: Separate where a processor stores information from whose law can reach it.
+
+  A processor carried one optional `country`, and the privacy policy flat-deduped it into a single
+  sentence. That conflated two facts a disclosure has to keep apart — **where the data rests** and
+  **which jurisdiction can compel access** — and privacy law turns on the second: the OPC's concern
+  is foreign _access_, not merely foreign storage.
+
+  Ordinary arrangements were inexpressible. Azure is data-resident in Canada and US-controlled;
+  Zoho can serve mail from a Canadian datacentre and telemetry from the US while being headquartered
+  in India; a Microsoft 365 tenant can be Canadian with its identity data in the US. For all of
+  them every available option was wrong: `country: "Canada"` rendered the incoherent _"outside of
+  Canada, including Canada"_, naming the operator's country asserted storage that wasn't happening,
+  and omitting it dropped the processor from the disclosure **silently**.
+
+  **New on a processor:**
+
+  ```jsonc
+  {
+    "name": "Zoho",
+    "purpose": "receiving and storing email sent to us",
+    "storage": [
+      { "country": "Canada", "scope": "mail and productivity data" },
+      { "country": "the United States", "scope": "analytics and telemetry" },
+    ],
+    "operatorCountry": "India",
+  }
+  ```
+
+  - `storage[]` — where information rests, each entry optionally `scope`d to a category. The scope
+    is what makes "Canadian tenant, identity data in the US" sayable.
+  - `operatorCountry` — the jurisdiction that can compel the provider to produce it. Gets its own
+    sentence: _"…established in, or controlled from, jurisdictions outside of Canada, including
+    India. Personal information those providers handle on our behalf may be subject to the laws of
+    those jurisdictions even when it is stored in Canada."_
+  - `country` still works, as shorthand asserting **both** facts — which is what it always
+    asserted, since the sentence it fed claimed storage and legal reach in one breath.
+
+  **Combining `country` with either explicit field is rejected** by `vitops validate`. Whether the
+  shorthand narrows the explicit fact or adds to it are two readings that make contradictory legal
+  claims, so neither is guessed.
+
+  A country in the policy's own jurisdiction is no longer treated as a transfer, which is the
+  `country: "Canada"` fix. Comparison ignores case and a leading "the".
+
+  ### This changes text you have already published
+
+  **Cloudflare, Cloudflare Turnstile, Vercel and Netlify now assert operator jurisdiction and no
+  storage.** They previously claimed `the United States` into a sentence saying "stored or processed
+  in" — a claim about the wrong fact. Cloudflare is anycast: a request from Toronto is answered from
+  a Toronto PoP, and Workers/R2 have residency controls the config cannot see.
+
+  So a site whose only foreign element is its host or Turnstile **stops claiming foreign storage**
+  and instead discloses foreign legal reach. That is a retraction in the direction of accuracy, and
+  it deserves a re-read. **If you pin a US region, say so** — declare a processor with
+  `storage: [{ country: "the United States" }]`. This generalises the rule the provider table
+  already applied to Matomo: "we don't know" is a fact.
+
+  **Everything else renders identically.** Google Analytics, Tag Manager, Clarity, Plausible,
+  Matomo Cloud and any processor you declared with `country` produce the same words as before,
+  because the shorthand expands to both facts and the operator sentence is suppressed when it would
+  only restate a country already disclosed as storage. The one cosmetic change: the closing
+  "subject to access requests…" sentence is now its own paragraph, since it is shared by both
+  clauses.
+
+  **A processor with no location at all is now reported** on stderr by `vitops legal`, naming the
+  document it will be missing from. It cannot appear in a transfer disclosure — there is nothing
+  true to say — but it used to vanish in silence, which is the failure that looks tidy. It is not a
+  validation error: a bare `{ name, purpose }` is still valid.
+
+  New exports from `@getvitops/generator`: `processorsMissingLocation`, `JURISDICTION_COUNTRIES`,
+  and the `ProcessorStorage` type. `PolicyVars` gains `jurisdictionCountry`, `storageCountries`,
+  `scopedStorage` and `operatorCountries`; `countries` is **deprecated but retained**, and still
+  names every country it ever named, so a custom template keeps rendering what it rendered.
+
+### Patch Changes
+
+- Updated dependencies [2c890c0]
+- Updated dependencies [e764090]
+  - @getvitops/generator@4.1.0
+  - @getvitops/utils@4.1.0
+
 ## 4.0.0
 
 ### Major Changes