@getvitops/cli 4.0.0 → 4.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@getvitops/cli",
-  "version": "4.0.0",
+  "version": "4.1.0",
   "description": "CLI for the Vitops design-system generator: generate, init, and validate a design-system.json.",
   "license": "MIT",
   "bin": {
@@ -22,8 +22,8 @@
     "access": "public"
   },
   "dependencies": {
-    "@getvitops/utils": "4.0.0",
-    "@getvitops/generator": "4.0.0"
+    "@getvitops/generator": "4.1.0",
+    "@getvitops/utils": "4.1.0"
   },
   "devDependencies": {
     "vitest": "^4.1.9"

package/skill/SKILL.md

@@ -123,7 +123,12 @@ where no provider covers the family.
   collect, the countries it names come from the providers in use. So the fix for a wrong
   policy is a corrected config, never hand-editing the output — the next build overwrites
   it. Declare processors the config cannot imply (payment, CRM, mail) under
-  `legal.privacyPolicy.processors`.
+  `legal.privacyPolicy.processors`. On each one, **where it stores data and whose law reaches
+  it are separate facts**: `storage: [{ country, scope? }]` is residency, `operatorCountry` is
+  the jurisdiction that can compel access, and `country` is shorthand for both — so a Canadian
+  region run by a US company is `storage: [{ country: "Canada" }]` with
+  `operatorCountry: "the United States"`, not one string. Combining `country` with either is
+  rejected.
   Generated from config, not legal advice — always tell the user to have it reviewed
   before publishing.
 - `vitops search notify` — tell search engines a deploy happened, from a **site config**'s