checkly 9.5.0 → 10.0.0-prerelease-4f88d60

package/README.md

@@ -89,6 +89,16 @@ npm install --save-dev checkly
 
 Official docs are over at [checklyhq.com/docs/cli](https://checklyhq.com/docs/cli/)
 
+## Account usage in v10
+
+Migration from v9:
+
+- Summary JSON renames `totals.credits.used` to `totals.creditsUsed` and removes `totals.credits.percentOfBudget` and embedded `projections`. Get forecasts with `checkly account usage projections <id>`.
+- Summary and series expose `usageTermsIds` instead of `usageTermsId`. Series replaces `warnings` with `coverage.gaps`.
+- Terms and series JSON use `{ data, pagination: { nextId, length } }`. Terms default to table output; use `term <id>` for detail.
+- `--from` and `--to` bound an inclusive UTC range. On `terms`, they select overlapping contracts rather than one contract covering `--to`.
+- `--check-type` is removed. Use `--pricing-rule` to select charges or `series --group-by checkType` for a check-type breakdown.
+
 # AI Agents & Coding Assistants
 
 The Checkly CLI is designed with AI-powered development in mind. With [**Monitoring as Code**](https://www.checklyhq.com/docs/concepts/monitoring-as-code/), your entire monitoring setup lives in TypeScript files — perfect for AI agents that can read, write, and reason about code.

package/bin/launch.cjs

@@ -10,6 +10,18 @@ void (async () => {
   const { loadDotenvFile } = await import('../dist/services/load-dotenv.js')
   await loadDotenvFile()
 
+  // A project's own checkly install must run its commands: the constructs
+  // in its files register with that install. Handing off before oclif loads
+  // keeps the hand-off cheap and leaves the project's CLI to do all the work.
+  try {
+    const { runWithProjectCli } = await import('../dist/services/project-cli.js')
+    if (await runWithProjectCli(process.argv.slice(2))) {
+      return
+    }
+  } catch {
+    // Run the command here; a broken install surfaces in execute() below.
+  }
+
   const { execute, settings } = await import('@oclif/core')
   settings.enableAutoTranspile = false
   await execute({ dir: __dirname })

package/dist/ai-context/context.js

@@ -133,6 +133,7 @@ import { Frequency } from 'checkly/constructs'
 export default defineConfig({
   projectName: "Production Monitoring Suite",
   logicalId: "prod-monitoring-2025",
+  // Must be this repo's own remote (\`git remote get-url origin\` as https). Never copy this example value.
   repoUrl: "https://github.com/acme/monitoring",
   checks: {
     activated: true,

package/dist/ai-context/context.js.map

@@ -1 +1 @@
-{"version":3,"file":"context.js","sourceRoot":"","sources":["../../src/ai-context/context.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,UAAU,GAAG;IACxB;QACE,EAAE,EAAE,sBAAsB;QAC1B,WAAW,EAAE,gFAAgF;KAC9F;IACD;QACE,EAAE,EAAE,0BAA0B;QAC9B,WAAW,EAAE,qEAAqE;KACnF;IACD;QACE,EAAE,EAAE,6BAA6B;QACjC,WAAW,EAAE,oFAAoF;KAClG;IACD;QACE,EAAE,EAAE,4BAA4B;QAChC,WAAW,EAAE,qEAAqE;KACnF;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,sDAAsD;KACpE;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,sDAAsD;KACpE;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,sDAAsD;KACpE;IACD;QACE,EAAE,EAAE,yBAAyB;QAC7B,WAAW,EAAE,gFAAgF;KAC9F;IACD;QACE,EAAE,EAAE,yBAAyB;QAC7B,WAAW,EAAE,wGAAwG;KACtH;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,uGAAuG;KACrH;IACD;QACE,EAAE,EAAE,+BAA+B;QACnC,WAAW,EAAE,8FAA8F;KAC5G;IACD;QACE,EAAE,EAAE,8BAA8B;QAClC,WAAW,EAAE,kDAAkD;KAChE;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,+DAA+D;KAC7E;IACD;QACE,EAAE,EAAE,0BAA0B;QAC9B,WAAW,EAAE,gPAAgP;KAC9P;IACD;QACE,EAAE,EAAE,iCAAiC;QACrC,WAAW,EAAE,6IAA6I;KAC3J;IACD;QACE,EAAE,EAAE,uBAAuB;QAC3B,WAAW,EAAE,8RAA8R;KAC5S;CACO,CAAA;AAEV,MAAM,CAAC,MAAM,sBAAsB,GAAG;IACpC;QACE,EAAE,EAAE,oBAAoB;QACxB,WAAW,EAAE,4HAA4H;KAC1I;IACD;QACE,EAAE,EAAE,sBAAsB;QAC1B,WAAW,EAAE,+GAA+G;KAC7H;IACD;QACE,EAAE,EAAE,2BAA2B;QAC/B,WAAW,EAAE,wHAAwH;KACtI;CACO,CAAA;AAEV,MAAM,CAAC,MAAM,sBAAsB,GAAG;IACpC;QACE,EAAE,EAAE,uBAAuB;QAC3B,WAAW,EAAE,uFAAuF;KACrG;CACO,CAAA;AAEV,MAAM,CAAC,MAAM,iBAAiB,GAAG;IAC/B;QACE,EAAE,EAAE,aAAa;QACjB,WAAW,EAAE,4FAA4F;KAC1G;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,+FAA+F;KAC7G;CACO,CAAA;AAEV,MAAM,CAAC,MAAM,KAAK,GAAG;IACnB,IAAI,EAAE,SAAS;IACf,WAAW,EAAE,iJAAiJ;CACtJ,CAAA;AAEV,MAAM,CAAC,MAAM,OAAO,GAAG;IACrB;QACE,EAAE,EAAE,YAAY;QAChB,WAAW,EAAE,4EAA4E;KAC1F;IACD;QACE,EAAE,EAAE,WAAW;QACf,WAAW,EAAE,wFAAwF;QACrG,UAAU,EAAE,UAAU;KACvB;IACD;QACE,EAAE,EAAE,aAAa;QACjB,WAAW,EAAE,0GAA0G;QACvH,UAAU,EAAE,sBAAsB;KACnC;IACD;QACE,EAAE,EAAE,aAAa;QACjB,WAAW,EAAE,mEAAmE;QAChF,UAAU,EAAE,sBAAsB;KACnC;IACD;QACE,EAAE,EAAE,QAAQ;QACZ,WAAW,EAAE,2FAA2F;QACxG,UAAU,EAAE,iBAAiB;KAC9B;CACO,CAAA;AASV,MAAM,CAAC,MAAM,eAAe,GAAkC;IAC5D,cAAc,EAAE;QACd,cAAc,EAAE,kCAAkC;QAClD,aAAa,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAgClB;QACG,SAAS,EAAE,oDAAoD;KAChE;IACD,aAAa,EAAE;QACb,cAAc,EAAE,iCAAiC;QACjD,iBAAiB,EACf,+EAA+E;QACjF,SAAS,EAAE,0DAA0D;KACtE;IACD,gBAAgB,EAAE;QAChB,cAAc,EAAE,oCAAoC;QACpD,aAAa,EAAE;;;;;;;;;;;;;;CAclB;QACG,SAAS,EAAE,6DAA6D;KACzE;IACD,SAAS,EAAE;QACT,cAAc,EAAE,6BAA6B;QAC7C,iBAAiB,EACf,mEAAmE;QACrE,SAAS,EAAE,sDAAsD;KAClE;IACD,eAAe,EAAE;QACf,cAAc,EAAE,mCAAmC;QACnD,iBAAiB,EACf,sFAAsF;QACxF,SAAS,EAAE,4DAA4D;KACxE;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,iBAAiB,EAAE,qDAAqD;QACxE,SAAS,EAAE,wDAAwD;KACpE;IACD,iBAAiB,EAAE;QACjB,cAAc,EAAE,qCAAqC;QACrD,iBAAiB,EACf,iEAAiE;QACnE,SAAS,EAAE,8DAA8D;KAC1E;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,iBAAiB,EAAE,qDAAqD;QACxE,SAAS,EAAE,wDAAwD;KACpE;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,iBAAiB,EAAE,qDAAqD;QACxE,SAAS,EAAE,wDAAwD;KACpE;IACD,YAAY,EAAE;QACZ,cAAc,EAAE,gCAAgC;QAChD,iBAAiB,EAAE,uDAAuD;QAC1E,SAAS,EAAE,yDAAyD;KACrE;IACD,YAAY,EAAE;QACZ,cAAc,EAAE,gCAAgC;QAChD,aAAa,EAAE;;;;;;;;;;;;;;;;;;;;;CAqBlB;QACG,SAAS,EAAE,yDAAyD;KACrE;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,aAAa,EAAE;;;;;;;;;;;;;;;;;;;;;;CAsBlB;QACG,SAAS,EAAE,wDAAwD;KACpE;IACD,kBAAkB,EAAE;QAClB,cAAc,EAAE,sCAAsC;QACtD,aAAa,EAAE;;;;;;;;;;;;;;;;;;;CAmBlB;QACG,SAAS,EAAE,+DAA+D;KAC3E;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,iBAAiB,EACf,4DAA4D;QAC9D,SAAS,EAAE,wDAAwD;KACpE;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,iBAAiB,EAAE,qDAAqD;QACxE,SAAS,EAAE,wDAAwD;KACpE;IACD,mBAAmB,EAAE;QACnB,cAAc,EAAE,uCAAuC;QACvD,iBAAiB,EACf,0DAA0D;QAC5D,SAAS,EAAE,gEAAgE;KAC5E;IACD,SAAS,EAAE;QACT,cAAc,EAAE,6BAA6B;QAC7C,iBAAiB,EACf,mEAAmE;QACrE,SAAS,EAAE,sDAAsD;KAClE;IACD,kBAAkB,EAAE;QAClB,cAAc,EAAE,sCAAsC;QACtD,iBAAiB,EACf,mEAAmE;QACrE,SAAS,EAAE,+DAA+D;KAC3E;IACD,gBAAgB,EAAE;QAChB,cAAc,EAAE,oCAAoC;QACpD,iBAAiB,EACf,+DAA+D;QACjE,SAAS,EAAE,6DAA6D;KACzE;IACD,mBAAmB,EAAE;QACnB,cAAc,EAAE,uCAAuC;QACvD,iBAAiB,EAAE,8CAA8C;QACjE,SAAS,EAAE,gEAAgE;KAC5E;IACD,wBAAwB,EAAE;QACxB,cAAc,EAAE,4CAA4C;QAC5D,iBAAiB,EAAE,wDAAwD;QAC3E,SAAS,EAAE,qEAAqE;KACjF;IACD,uBAAuB,EAAE;QACvB,cAAc,EAAE,2CAA2C;QAC3D,iBAAiB,EAAE,8DAA8D;QACjF,SAAS,EAAE,oEAAoE;KAChF;IACD,sBAAsB,EAAE;QACtB,cAAc,EAAE,0CAA0C;QAC1D,iBAAiB,EAAE,yDAAyD;QAC5E,SAAS,EAAE,mEAAmE;KAC/E;IACD,wBAAwB,EAAE;QACxB,cAAc,EAAE,4CAA4C;QAC5D,iBAAiB,EAAE,6DAA6D;QAChF,SAAS,EAAE,qEAAqE;KACjF;IACD,qBAAqB,EAAE;QACrB,cAAc,EAAE,yCAAyC;QACzD,iBAAiB,EAAE,sDAAsD;QACzE,SAAS,EAAE,kEAAkE;KAC9E;CACF,CAAA"}
+{"version":3,"file":"context.js","sourceRoot":"","sources":["../../src/ai-context/context.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,UAAU,GAAG;IACxB;QACE,EAAE,EAAE,sBAAsB;QAC1B,WAAW,EAAE,gFAAgF;KAC9F;IACD;QACE,EAAE,EAAE,0BAA0B;QAC9B,WAAW,EAAE,qEAAqE;KACnF;IACD;QACE,EAAE,EAAE,6BAA6B;QACjC,WAAW,EAAE,oFAAoF;KAClG;IACD;QACE,EAAE,EAAE,4BAA4B;QAChC,WAAW,EAAE,qEAAqE;KACnF;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,sDAAsD;KACpE;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,sDAAsD;KACpE;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,sDAAsD;KACpE;IACD;QACE,EAAE,EAAE,yBAAyB;QAC7B,WAAW,EAAE,gFAAgF;KAC9F;IACD;QACE,EAAE,EAAE,yBAAyB;QAC7B,WAAW,EAAE,wGAAwG;KACtH;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,uGAAuG;KACrH;IACD;QACE,EAAE,EAAE,+BAA+B;QACnC,WAAW,EAAE,8FAA8F;KAC5G;IACD;QACE,EAAE,EAAE,8BAA8B;QAClC,WAAW,EAAE,kDAAkD;KAChE;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,+DAA+D;KAC7E;IACD;QACE,EAAE,EAAE,0BAA0B;QAC9B,WAAW,EAAE,gPAAgP;KAC9P;IACD;QACE,EAAE,EAAE,iCAAiC;QACrC,WAAW,EAAE,6IAA6I;KAC3J;IACD;QACE,EAAE,EAAE,uBAAuB;QAC3B,WAAW,EAAE,8RAA8R;KAC5S;CACO,CAAA;AAEV,MAAM,CAAC,MAAM,sBAAsB,GAAG;IACpC;QACE,EAAE,EAAE,oBAAoB;QACxB,WAAW,EAAE,4HAA4H;KAC1I;IACD;QACE,EAAE,EAAE,sBAAsB;QAC1B,WAAW,EAAE,+GAA+G;KAC7H;IACD;QACE,EAAE,EAAE,2BAA2B;QAC/B,WAAW,EAAE,wHAAwH;KACtI;CACO,CAAA;AAEV,MAAM,CAAC,MAAM,sBAAsB,GAAG;IACpC;QACE,EAAE,EAAE,uBAAuB;QAC3B,WAAW,EAAE,uFAAuF;KACrG;CACO,CAAA;AAEV,MAAM,CAAC,MAAM,iBAAiB,GAAG;IAC/B;QACE,EAAE,EAAE,aAAa;QACjB,WAAW,EAAE,4FAA4F;KAC1G;IACD;QACE,EAAE,EAAE,wBAAwB;QAC5B,WAAW,EAAE,+FAA+F;KAC7G;CACO,CAAA;AAEV,MAAM,CAAC,MAAM,KAAK,GAAG;IACnB,IAAI,EAAE,SAAS;IACf,WAAW,EAAE,iJAAiJ;CACtJ,CAAA;AAEV,MAAM,CAAC,MAAM,OAAO,GAAG;IACrB;QACE,EAAE,EAAE,YAAY;QAChB,WAAW,EAAE,4EAA4E;KAC1F;IACD;QACE,EAAE,EAAE,WAAW;QACf,WAAW,EAAE,wFAAwF;QACrG,UAAU,EAAE,UAAU;KACvB;IACD;QACE,EAAE,EAAE,aAAa;QACjB,WAAW,EAAE,0GAA0G;QACvH,UAAU,EAAE,sBAAsB;KACnC;IACD;QACE,EAAE,EAAE,aAAa;QACjB,WAAW,EAAE,mEAAmE;QAChF,UAAU,EAAE,sBAAsB;KACnC;IACD;QACE,EAAE,EAAE,QAAQ;QACZ,WAAW,EAAE,2FAA2F;QACxG,UAAU,EAAE,iBAAiB;KAC9B;CACO,CAAA;AASV,MAAM,CAAC,MAAM,eAAe,GAAkC;IAC5D,cAAc,EAAE;QACd,cAAc,EAAE,kCAAkC;QAClD,aAAa,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiClB;QACG,SAAS,EAAE,oDAAoD;KAChE;IACD,aAAa,EAAE;QACb,cAAc,EAAE,iCAAiC;QACjD,iBAAiB,EACf,+EAA+E;QACjF,SAAS,EAAE,0DAA0D;KACtE;IACD,gBAAgB,EAAE;QAChB,cAAc,EAAE,oCAAoC;QACpD,aAAa,EAAE;;;;;;;;;;;;;;CAclB;QACG,SAAS,EAAE,6DAA6D;KACzE;IACD,SAAS,EAAE;QACT,cAAc,EAAE,6BAA6B;QAC7C,iBAAiB,EACf,mEAAmE;QACrE,SAAS,EAAE,sDAAsD;KAClE;IACD,eAAe,EAAE;QACf,cAAc,EAAE,mCAAmC;QACnD,iBAAiB,EACf,sFAAsF;QACxF,SAAS,EAAE,4DAA4D;KACxE;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,iBAAiB,EAAE,qDAAqD;QACxE,SAAS,EAAE,wDAAwD;KACpE;IACD,iBAAiB,EAAE;QACjB,cAAc,EAAE,qCAAqC;QACrD,iBAAiB,EACf,iEAAiE;QACnE,SAAS,EAAE,8DAA8D;KAC1E;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,iBAAiB,EAAE,qDAAqD;QACxE,SAAS,EAAE,wDAAwD;KACpE;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,iBAAiB,EAAE,qDAAqD;QACxE,SAAS,EAAE,wDAAwD;KACpE;IACD,YAAY,EAAE;QACZ,cAAc,EAAE,gCAAgC;QAChD,iBAAiB,EAAE,uDAAuD;QAC1E,SAAS,EAAE,yDAAyD;KACrE;IACD,YAAY,EAAE;QACZ,cAAc,EAAE,gCAAgC;QAChD,aAAa,EAAE;;;;;;;;;;;;;;;;;;;;;CAqBlB;QACG,SAAS,EAAE,yDAAyD;KACrE;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,aAAa,EAAE;;;;;;;;;;;;;;;;;;;;;;CAsBlB;QACG,SAAS,EAAE,wDAAwD;KACpE;IACD,kBAAkB,EAAE;QAClB,cAAc,EAAE,sCAAsC;QACtD,aAAa,EAAE;;;;;;;;;;;;;;;;;;;CAmBlB;QACG,SAAS,EAAE,+DAA+D;KAC3E;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,iBAAiB,EACf,4DAA4D;QAC9D,SAAS,EAAE,wDAAwD;KACpE;IACD,WAAW,EAAE;QACX,cAAc,EAAE,+BAA+B;QAC/C,iBAAiB,EAAE,qDAAqD;QACxE,SAAS,EAAE,wDAAwD;KACpE;IACD,mBAAmB,EAAE;QACnB,cAAc,EAAE,uCAAuC;QACvD,iBAAiB,EACf,0DAA0D;QAC5D,SAAS,EAAE,gEAAgE;KAC5E;IACD,SAAS,EAAE;QACT,cAAc,EAAE,6BAA6B;QAC7C,iBAAiB,EACf,mEAAmE;QACrE,SAAS,EAAE,sDAAsD;KAClE;IACD,kBAAkB,EAAE;QAClB,cAAc,EAAE,sCAAsC;QACtD,iBAAiB,EACf,mEAAmE;QACrE,SAAS,EAAE,+DAA+D;KAC3E;IACD,gBAAgB,EAAE;QAChB,cAAc,EAAE,oCAAoC;QACpD,iBAAiB,EACf,+DAA+D;QACjE,SAAS,EAAE,6DAA6D;KACzE;IACD,mBAAmB,EAAE;QACnB,cAAc,EAAE,uCAAuC;QACvD,iBAAiB,EAAE,8CAA8C;QACjE,SAAS,EAAE,gEAAgE;KAC5E;IACD,wBAAwB,EAAE;QACxB,cAAc,EAAE,4CAA4C;QAC5D,iBAAiB,EAAE,wDAAwD;QAC3E,SAAS,EAAE,qEAAqE;KACjF;IACD,uBAAuB,EAAE;QACvB,cAAc,EAAE,2CAA2C;QAC3D,iBAAiB,EAAE,8DAA8D;QACjF,SAAS,EAAE,oEAAoE;KAChF;IACD,sBAAsB,EAAE;QACtB,cAAc,EAAE,0CAA0C;QAC1D,iBAAiB,EAAE,yDAAyD;QAC5E,SAAS,EAAE,mEAAmE;KAC/E;IACD,wBAAwB,EAAE;QACxB,cAAc,EAAE,4CAA4C;QAC5D,iBAAiB,EAAE,6DAA6D;QAChF,SAAS,EAAE,qEAAqE;KACjF;IACD,qBAAqB,EAAE;QACrB,cAAc,EAAE,yCAAyC;QACzD,iBAAiB,EAAE,sDAAsD;QACzE,SAAS,EAAE,kEAAkE;KAC9E;CACF,CAAA"}

package/dist/ai-context/onboarding-boilerplate/checkly-config-template.ts

@@ -10,6 +10,8 @@ const config = defineConfig({
   * See https://www.checklyhq.com/docs/cli/constructs/ to learn more about logical IDs.
   */
   logicalId: '{{logicalId}}',
+  /* The URL of this project's git repository, used to link checks to their source code */
+  repoUrl: '{{repoUrl}}',
   /* Sets default values for Checks */
   checks: {
     /* A default for how often your Check should run in minutes */
@@ -40,8 +42,6 @@ const config = defineConfig({
   cli: {
     /* The default datacenter location to use when running npx checkly test */
     runLocation: 'eu-central-1',
-    /* An array of default reporters to use when a reporter is not specified with the "--reporter" flag */
-    reporters: ['list'],
     /* How many times to retry a failing test run when running `npx checkly test` or `npx checkly trigger` (max. 3) */
     retries: 0,
   },

package/dist/ai-context/public-skills/checkly/SKILL.md

@@ -17,15 +17,40 @@ Before your first command that talks to the Checkly API, establish your path:
 1. **No shell access** (chat-only session): stop following this skill and use the Checkly MCP tools if they're connected; if not, tell the user you need either a shell or the Checkly MCP server to work with Checkly.
 2. **Shell access**: run `npx checkly whoami` once.
    - **Succeeds** → use the CLI for everything and keep following this skill, even when Checkly MCP tools are also connected.
-   - **Fails with an auth error** → route by task:
-     - *Authoring, testing, or deploying checks*: MCP cannot do this. Ask the user to authenticate — `npx checkly login`, or `CHECKLY_API_KEY` + `CHECKLY_ACCOUNT_ID` in the environment or `.env` — then re-run `whoami`. Don't work around a missing login.
-     - *Live account work* (status, results, test sessions, RCA, triggering, incidents): fall back to the Checkly MCP tools if they're connected. Call the MCP `whoami` tool first and tell the user which account you're operating on. If MCP isn't connected either, ask the user to authenticate the CLI as above.
+   - **Fails with an auth error, or prints an `action_required` login line** (not logged in) → route by task:
+     - *Authoring, testing, or deploying checks*: MCP cannot do this. Log in through the CLI yourself (see "Logging in as an agent" below), or, when the user prefers keys, ask for `CHECKLY_API_KEY` + `CHECKLY_ACCOUNT_ID` in the environment or `.env`. Then re-run `whoami`. Don't work around a missing login.
+     - *Live account work* (status, results, test sessions, RCA, triggering, incidents): fall back to the Checkly MCP tools if they're connected; ignore the login code. Call the MCP `whoami` tool first and tell the user which account you're operating on. If MCP isn't connected either, ask the user to authenticate the CLI as above.
 
 Two rules that survive any fallback:
 
 - **Account parity.** CLI auth and the MCP session can point at different accounts — users often belong to several. Never mix CLI and MCP results in one task without confirming both use the same account ID, and always name the account after a fallback.
 - **Writes still need confirmation.** The CLI's confirmation protocol (below) does not travel with you to MCP. If you fall back for a write action (e.g. creating an incident), present the intended change and get the user's approval before calling the tool.
 
+## Logging in as an agent
+
+`npx checkly login` needs no terminal, and any command that requires authentication starts it for you when no credentials are stored, so you rarely run it by hand. It prints one JSON line and exits; when another command started it, the line goes to stderr. Relay what it says; never guess:
+
+- `{"status":"action_required","reason":"login_required","verification_uri_complete":…,"user_code":…,"expires_in":…}` — a human must approve. Give the user the URL and the code (valid for `expires_in` seconds). Users without a Checkly account can sign up on the same page. Then, without waiting for the user to say they are done, run the first `next` command (`npx checkly login --wait`): it returns once they have approved, with the line below. Run it in the background: it can wait up to `expires_in` seconds, often longer than your shell's command timeout. If it is stopped before the user approves, run it again; the same code stays valid. (When another command started the login, run that command again afterwards, as the second `next` entry says.) A run without `--wait` before the approval shows the code again (or a new one when the old one is about to expire); always relay the latest `user_code`. Until the login is done, don't run several Checkly commands in parallel.
+  - If the line has a `verification_uri` but no `user_code`, the URL must be opened on the same machine as the CLI, and the command waits for it instead of exiting: run it in the background so you can relay the URL.
+  - If it has no URL and its `next` has no `when`, run that command now, in the background, relay what it prints, and run the original command again once the user is done (running it earlier only repeats this line).
+- `{"status":"action_required","reason":"select_account","choices":[…],"next":[…]}` — the key is stored, but the user belongs to several accounts. No account is the default yet, so every command stops here until one is chosen or named. Ask the user which one, unless they already named it: an account name or id they gave you that matches exactly one entry in `choices` counts as their choice. Never pick one yourself, even if you cannot ask: stop and say which accounts are available. There is no second browser step. Then either:
+  - run `npx checkly login --account-id <id>` to make it the default for later commands, or
+  - put `CHECKLY_ACCOUNT_ID=<id>` in front of a command to run just that command against the account (see "Working with several accounts" below).
+- `{"status":"success","reason":…,"message":…,"accountId":…,"accountName":…,"defaultAccount":…}` — done. `defaultAccount` is the stored default (`null` when none is stored); while `CHECKLY_ACCOUNT_ID` is set, commands use that account instead, as the message says. Tell the user which account you are on.
+- `{"status":"error","reason":…,"message":…}` — report the message; do not retry in a loop. `reason` is one of `access_denied`, `expired_token`, `code_used` (run the login again for a new code), `account_not_found`, `no_accounts`, `invalid_response`, `network_error` (the login server could not be reached), `api_error`, `env_credentials` (`CHECKLY_API_KEY` is set, so API key credentials are in use; the user must remove them to log in) or `login_failed`. To log in as a different user, run `npx checkly logout` first.
+
+On a host without a browser set `CHECKLY_NO_BROWSER=1` so the CLI does not try to open one; the URL and code are printed regardless. The flag forms are `--account-id` and `--no-browser`.
+
+### Working with several accounts
+
+A `checkly login` belongs to the user, not to one account, so it works with every account they belong to. The default account is the one commands use unless told otherwise.
+
+- **List accounts:** `npx checkly whoami` names the account in use, the default and the user's other accounts. `--output json` adds `accountSource` (`login`: the default; `account_override`: `CHECKLY_ACCOUNT_ID` picks the account; `environment`: API key credentials via `CHECKLY_API_KEY`, which belong to one account) and `defaultAccount` (`null` for API key credentials, and while `CHECKLY_ACCOUNT_ID` picks the account and no default is chosen yet; without either, commands stop at `select_account` instead).
+- **Use another account for one command:** put `CHECKLY_ACCOUNT_ID=<id>` in front of it (`CHECKLY_ACCOUNT_ID=<id> npx checkly test-sessions get <id>`). It uses the stored login and leaves the default as it is. Prefer this when a task touches an account other than the default (e.g. a CI test session in another account), so you don't change the default behind the user's back. Without a stored login, the command logs in first (relay the code as above) and then uses that account, without storing a default. An id that is not one of the user's accounts fails with the list of the accounts the login works with.
+- **`CHECKLY_ACCOUNT_ID` in the shell or `.env`:** without `CHECKLY_API_KEY`, it works like the prefix for every command until it is unset, whatever the default is. A login then needs no account choice: commands use that account, and no default is stored. A prefix on the command line wins over the value in `.env` (`.env` never overrides a variable that is already set). `whoami` says so; `login` and `switch` warn that it takes precedence over the default they store. If the user wants the default to apply, they have to remove it (a project may keep it in `.env` on purpose, to pin that project to an account).
+- **Change the default:** only when the user asks for it, run `npx checkly switch --account-id <id>`. It applies at once (no confirmation step, nothing to undo but switching back) and prints a plain `Account switched to …` line; check with `npx checkly whoami`. Without `--account-id`, `switch` prints a `select_account` line with the stored `defaultAccount` (or `null`) and the `choices`.
+- **Not found?** When a lookup by ID finds nothing, the message names the account that was searched; with `--output json` the error also has `hint` and `searchedAccount` fields. If the resource may be in another account, run the command again with `CHECKLY_ACCOUNT_ID=<id>` for each likely account.
+
 ## Always load the current action list first
 
 **Required:** Before answering any Checkly question, run `npx checkly skills` to get the current and up-to-date action list. Do not rely on memory or prior context — the CLI is the source of truth and actions might change between releases. `npx checkly skills` runs locally — it needs no authentication or API access, so it works before you've established your path above.
@@ -54,12 +79,16 @@ Run `npx checkly skills manage` for the full reference.
 
 ## Confirmation Protocol
 
-Write commands (e.g. `incidents create`, `deploy`, `destroy`) return exit code 2 with a `confirmation_required` JSON envelope instead of executing. **Always present the `changes` to the user and wait for approval before running the `confirmCommand`.** This applies to every write command individually — updates and resolutions need confirmation too, not just the initial create.
+Write commands (e.g. `incidents create`, `deploy`, `destroy`) return exit code 3 with a `confirmation_required` JSON envelope instead of executing. **Always present the `changes` to the user and wait for approval before running the `confirmCommand`.** This applies to every write command individually — updates and resolutions need confirmation too, not just the initial create. The one exception is a `checkly deploy` whose plan has no changes: there is nothing to approve, so it prints `No changes.`, records the deployment, schedules no checks unless `--schedule-on-deploy --schedule-on-deploy-scope=all` is passed, and exits with code 0. A deploy schedules checks only when `--schedule-on-deploy` is passed: then only the checks it changed, or with `--schedule-on-deploy-scope=all` every check, unless there are more of them than the scheduling threshold allows (`--schedule-on-deploy-threshold`, by default set by Checkly), leaving out the checks that run more often than the minimum frequency for deploys (`--schedule-on-deploy-min-frequency`, by default set by Checkly).
 
-The `confirmCommand` is the approved command, ready to run verbatim: it repeats the flags you passed and already ends in `--force`. Run it as-is once the user approves — don't add `--force` to a command yourself, and don't add flags the user didn't ask for.
+The `confirmCommand` is the approved command, ready to run verbatim: it starts with `npx checkly` so the project's own CLI runs, repeats the flags you passed (and, for `deploy`, pins the plan it showed with `--plan-token`) and already ends in `--force`. Run it as-is once the user approves — don't add `--force` to a command yourself, don't drop the `npx`, and don't add flags the user didn't ask for.
 
 Run `npx checkly skills communicate` for the full protocol details, or `npx checkly skills configure` for what `deploy` confirms.
 
+## Output Streams and Exit Codes
+
+stdout carries only the command's result: results, `--output json` documents (most failures print a JSON error document too), API pass-through bodies, and the confirmation/dry-run envelopes above. Progress, warnings, hints, prompts, and human-readable errors go to stderr, so `npx checkly <command> --output json | jq` sees nothing but the JSON. Check the exit code first, since some failures leave stdout empty: 0 success (degraded checks do not fail a run; read the results to spot them), 1 failure, 2 a usage error, 3 `confirmation_required`, 127 an unknown command.
+
 ## API Pass-Through (fallback for any endpoint)
 
 When no dedicated CLI command exists for an endpoint, use `npx checkly api` to make authenticated requests directly. The CLI handles auth headers and base URL automatically.

package/dist/ai-context/skills-command/references/communicate.md

@@ -4,7 +4,7 @@ Open incidents and lead customer communications via status pages.
 
 ## Confirmation Protocol
 
-Write commands (`incidents create`, `incidents update`, `incidents resolve`, `deploy`, `destroy`, `import commit`, `import cancel`) require confirmation before executing. When the CLI detects an agent environment, it returns a JSON envelope with exit code 2 instead of executing:
+Write commands (`incidents create`, `incidents update`, `incidents resolve`, `deploy`, `destroy`, `import commit`, `import cancel`) require confirmation before executing. When the CLI detects an agent environment, it returns a JSON envelope with exit code 3 instead of executing:
 
 ```json
 {
@@ -13,23 +13,26 @@ Write commands (`incidents create`, `incidents update`, `incidents resolve`, `de
   "description": "Create incident on status page",
   "classification": { "readOnly": false, "destructive": false, "idempotent": false },
   "changes": ["Will create incident \"DB outage\" on status page \"Acme\"", "Severity: major"],
-  "confirmCommand": "checkly incidents create --title=\"DB outage\" --status-page-id=\"sp-1\" --severity=\"major\" --force"
+  "confirmCommand": "npx checkly incidents create --title=\"DB outage\" --status-page-id=\"sp-1\" --severity=\"major\" --force"
 }
 ```
 
 **Rules for agents:**
 
-1. When exit code is 2 and output contains `"status": "confirmation_required"`, **always present the `changes` array to the user** and ask for confirmation.
+1. When stdout contains `"status": "confirmation_required"` (exit code 3), **always present the `changes` array to the user** and ask for confirmation.
 2. **Run the `confirmCommand` verbatim, and only after the user explicitly approves.** It is normally the command you just ran, plus `--force` to skip the second prompt. Don't append `--force` to anything yourself, and don't edit the `confirmCommand` — changing its flags changes what you were authorized to do.
 3. This applies to **every** write command, not just the first one. Incident updates and resolutions also require confirmation.
 4. Use `--dry-run` to preview what a command will do without executing or prompting.
 5. Read-only commands (`incidents list`, `status-pages list`) execute immediately without confirmation.
+6. A `checkly deploy` whose plan has no changes is the one write command that returns no envelope: it prints `No changes.`, records the deployment, schedules no checks unless `--schedule-on-deploy --schedule-on-deploy-scope=all` is passed, and exits with code 0. A deploy schedules checks only when `--schedule-on-deploy` is passed: then only the checks it changed, or with `--schedule-on-deploy-scope=all` every check, unless there are more of them than the scheduling threshold allows (`--schedule-on-deploy-threshold`, by default set by Checkly), leaving out the checks that run more often than the minimum frequency for deploys (`--schedule-on-deploy-min-frequency`, by default set by Checkly).
 
-The `confirmCommand` omits flags left at their default, so a bare `npx checkly deploy` confirms as `checkly deploy --force` rather than echoing back every boolean the parser filled in. Treat every flag you see there as deliberate.
+The `confirmCommand` omits flags left at their default, so a bare `npx checkly deploy` confirms as `npx checkly deploy --plan-token="<token>" --force`: the token of the plan it showed, and none of the booleans the parser filled in. Treat every flag you see there as deliberate.
 
 ### Commands that pin a resolved target
 
-A command that picks its own target before confirming writes that target back into the `confirmCommand`. `import commit` and `import cancel` do this: run without `--plan-id` they select the only candidate plan themselves, and confirm as `checkly import commit --plan-id="<resolved-id>" --force` — carrying a flag you never passed. That is deliberate: the pinned ID guarantees the approved run acts on the plan whose `changes` you showed the user, not on whatever happens to be pending by then. Run the `confirmCommand` exactly as returned; do not strip the flag or fall back to the bare command.
+A command that picks its own target before confirming writes that target back into the `confirmCommand`. `import commit` and `import cancel` do this: run without `--plan-id` they select the only candidate plan themselves, and confirm as `npx checkly import commit --plan-id="<resolved-id>" --force` — carrying a flag you never passed. That is deliberate: the pinned ID guarantees the approved run acts on the plan whose `changes` you showed the user, not on whatever happens to be pending by then. Run the `confirmCommand` exactly as returned; do not strip the flag or fall back to the bare command.
+
+`deploy` pins the same way, with `--plan-token`: the token identifies the state of the account the plan was computed against, and the pinned run refuses to deploy — writing nothing — if anything changed in between. Re-run `checkly deploy` in that case; it computes a fresh plan to confirm. A `deploy --no-plan` has no plan to pin and takes no token. Do not carry a token over from an earlier run, and do not re-send a refused one.
 
 ## Available Commands
 

package/dist/ai-context/skills-command/references/configure-api-checks.md

@@ -13,7 +13,7 @@
 **Reference:** https://www.checklyhq.com/docs/constructs/api-check/
 
 ```typescript
-import { AlertEscalationBuilder, ApiCheck, Frequency, RetryStrategyBuilder } from 'checkly/constructs'
+import { ApiCheck, Frequency, RetryStrategyBuilder } from 'checkly/constructs'
 
 new ApiCheck('example-api-check', {
   name: 'Example API Check',
@@ -25,19 +25,11 @@ new ApiCheck('example-api-check', {
   },
   degradedResponseTime: 5000,
   maxResponseTime: 20000,
-  activated: true,
   locations: [
     'eu-central-1',
     'eu-west-2',
   ],
   frequency: Frequency.EVERY_5M,
-  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
-    amount: 0,
-    interval: 5,
-  }, {
-    enabled: false,
-    percentage: 10,
-  }),
   retryStrategy: RetryStrategyBuilder.noRetries(),
   runParallel: true,
   request: {

package/dist/ai-context/skills-command/references/configure-browser-checks.md

@@ -10,7 +10,7 @@
 **Reference:** https://www.checklyhq.com/docs/constructs/browser-check/
 
 ```typescript
-import { AlertEscalationBuilder, BrowserCheck, Frequency, RetryStrategyBuilder } from 'checkly/constructs'
+import { BrowserCheck, Frequency, RetryStrategyBuilder } from 'checkly/constructs'
 
 new BrowserCheck('example-browser-check', {
   name: 'Example Browser Check',
@@ -23,13 +23,6 @@ new BrowserCheck('example-browser-check', {
     'eu-west-2',
   ],
   frequency: Frequency.EVERY_10M,
-  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
-    amount: 0,
-    interval: 5,
-  }, {
-    enabled: false,
-    percentage: 10,
-  }),
   retryStrategy: RetryStrategyBuilder.noRetries(),
   runParallel: true,
 })

package/dist/ai-context/skills-command/references/configure-check-groups.md

@@ -12,5 +12,6 @@ import { CheckGroupV2 } from 'checkly/constructs'
 
 export const exampleGroup = new CheckGroupV2('example-group', {
   name: 'Example Group',
+  concurrency: 1,
 })
 ```

package/dist/ai-context/skills-command/references/configure-dns-monitors.md

@@ -8,25 +8,17 @@
 **Reference:** https://www.checklyhq.com/docs/constructs/dns-monitor/
 
 ```typescript
-import { AlertEscalationBuilder, DnsAssertionBuilder, DnsMonitor, Frequency, RetryStrategyBuilder } from 'checkly/constructs'
+import { DnsAssertionBuilder, DnsMonitor, Frequency, RetryStrategyBuilder } from 'checkly/constructs'
 
 new DnsMonitor('example-dns-monitor', {
   name: 'Example DNS Monitor',
   degradedResponseTime: 500,
   maxResponseTime: 1000,
-  activated: true,
   locations: [
     'eu-central-1',
     'eu-north-1',
   ],
   frequency: Frequency.EVERY_10M,
-  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
-    amount: 0,
-    interval: 5,
-  }, {
-    enabled: false,
-    percentage: 10,
-  }),
   retryStrategy: RetryStrategyBuilder.noRetries(),
   request: {
     recordType: 'AAAA',

package/dist/ai-context/skills-command/references/configure-grpc-monitors.md

@@ -35,3 +35,27 @@ new GrpcMonitor('grpc-api-health', {
   },
 })
 ```
+
+## FlatBuffers services
+
+Only applies when the service uses FlatBuffers instead of Protobuf. Protobuf is the default; omit `grpcConfig.encoding` otherwise.
+
+- FlatBuffers requires `BEHAVIOR` mode; `HEALTH` mode always uses Protobuf.
+- Compile the `.fbs` source schema to a binary `.bfbs` schema with `flatc -b --schema --bfbs-builtins schema.fbs`. `--bfbs-builtins` preserves attributes used for streaming and nested FlatBuffers fields.
+- Set `grpcConfig.encoding` to `'FLATBUFFERS'` and load the compiled schema as base64 into `bfbsContent`. Do not set `serviceDefinition` or `protoContent`; FlatBuffers has no server reflection.
+
+```typescript
+import { readFileSync } from 'node:fs'
+
+request: {
+  url: 'grpc.example.com',
+  port: 443,
+  grpcConfig: {
+    mode: 'BEHAVIOR',
+    encoding: 'FLATBUFFERS',
+    bfbsContent: readFileSync('schema.bfbs').toString('base64'),
+    method: 'example.Greeter/Greet',
+    message: JSON.stringify({ name: 'Checkly' }),
+  },
+}
+```

package/dist/ai-context/skills-command/references/configure-heartbeat-monitors.md

@@ -5,7 +5,7 @@
 **Reference:** https://www.checklyhq.com/docs/constructs/heartbeat-monitor/
 
 ```typescript
-import { AlertEscalationBuilder, Frequency, HeartbeatMonitor, RetryStrategyBuilder } from 'checkly/constructs'
+import { Frequency, HeartbeatMonitor, RetryStrategyBuilder } from 'checkly/constructs'
 
 new HeartbeatMonitor('example-heartbeat-monitor', {
   name: 'Example Heartbeat Monitor',
@@ -13,15 +13,7 @@ new HeartbeatMonitor('example-heartbeat-monitor', {
   periodUnit: 'hours',
   grace: 30,
   graceUnit: 'minutes',
-  activated: true,
   frequency: Frequency.EVERY_10S,
-  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
-    amount: 0,
-    interval: 5,
-  }, {
-    enabled: false,
-    percentage: 10,
-  }),
   retryStrategy: RetryStrategyBuilder.noRetries(),
   runParallel: true,
 })

package/dist/ai-context/skills-command/references/configure-icmp-monitors.md

@@ -10,7 +10,7 @@
 **Reference:** https://www.checklyhq.com/docs/constructs/icmp-monitor/
 
 ```typescript
-import { AlertEscalationBuilder, Frequency, IcmpAssertionBuilder, IcmpMonitor, RetryStrategyBuilder } from 'checkly/constructs'
+import { Frequency, IcmpAssertionBuilder, IcmpMonitor, RetryStrategyBuilder } from 'checkly/constructs'
 
 new IcmpMonitor('example-icmp-monitor', {
   name: 'Example ICMP Monitor',
@@ -24,19 +24,11 @@ new IcmpMonitor('example-icmp-monitor', {
   },
   degradedPacketLossThreshold: 10,
   maxPacketLossThreshold: 20,
-  activated: true,
   locations: [
     'eu-central-1',
     'eu-north-1',
   ],
   frequency: Frequency.EVERY_10M,
-  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
-    amount: 0,
-    interval: 5,
-  }, {
-    enabled: false,
-    percentage: 10,
-  }),
   retryStrategy: RetryStrategyBuilder.noRetries(),
 })
 ```

package/dist/ai-context/skills-command/references/configure-multistep-checks.md

@@ -8,26 +8,18 @@
 **Reference:** https://www.checklyhq.com/docs/constructs/multistep-check/
 
 ```typescript
-import { AlertEscalationBuilder, Frequency, MultiStepCheck, RetryStrategyBuilder } from 'checkly/constructs'
+import { Frequency, MultiStepCheck, RetryStrategyBuilder } from 'checkly/constructs'
 
 new MultiStepCheck('example-multi-step-check', {
   name: 'Example Multistep Check',
   code: {
     entrypoint: './example-multistep-check.spec.ts',
   },
-  activated: true,
   locations: [
     'eu-central-1',
     'eu-west-2',
   ],
   frequency: Frequency.EVERY_1H,
-  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
-    amount: 0,
-    interval: 5,
-  }, {
-    enabled: false,
-    percentage: 10,
-  }),
   retryStrategy: RetryStrategyBuilder.noRetries(),
   runParallel: true,
 })

package/dist/ai-context/skills-command/references/configure-playwright-checks.md

@@ -19,7 +19,7 @@
   - The workspace's package manager binary must be available on the machine running the CLI. pnpm resolves against the workspace's own store plus cached registry metadata, npm reuses its cached metadata, and both only contact the registry for misses; yarn Berry and bun regenerate offline.
   - When pruning was needed but cannot run or cannot verify its result, the original lockfile ships unchanged and the CLI prints a note explaining why — follow it (a timed-out prune's note names `CHECKLY_LOCKFILE_PRUNE_TIMEOUT=<seconds>`, which raises the default 30 s budget). Skips are silent when there is nothing to prune, or when pruning is disabled via `CHECKLY_LOCKFILE_PRUNE=0`; silent skip reasons, a timed-out prune's partial package manager output, and per-entry embed match details are visible under `DEBUG='checkly:cli:services:check-parser:*'` and `DEBUG='checkly:cli:services:embedded-packages'`.
   - For pnpm projects with `patchedDependencies`, patches belonging to unbundled workspace members are filtered out automatically. A note naming stale patch declarations means the lockfile is out of date with the config — refresh it with a regular install.
-- Checkly caches installed dependencies between runs, keyed off the workspace's dependency inputs (the lock file, every workspace member's `package.json` and `.npmrc` — whether or not the member is in the bundle) plus the bundle's own install inputs, so the key can change without a file edit, e.g. when a different set of workspace members lands in the bundle. To force a reinstall for deployed checks, set `runner.cache.install.version` (a string or a safe integer) at the top level of `checkly.config.ts` — not per check — and change its value whenever the cache should be invalidated; deployed, scheduled checks pick up the change on the next `checkly deploy`. If the config still declares the deprecated `caching.dependencyCache.version`, remove it — setting both fails config loading. Unset or empty values leave the cache key unchanged, so a dynamic value such as `version: process.env.DEPENDENCY_CACHE_VERSION` is safe when the variable is not always set. For a one-off reinstall during an ad-hoc run, use the `--refresh-cache` flag on `checkly test`, `checkly pw-test`, `checkly trigger`, or `checkly checks run` instead.
+- Checkly caches installed dependencies between runs, keyed off the workspace's dependency inputs (the lock file, every workspace member's `package.json` and `.npmrc` — whether or not the member is in the bundle) plus the bundle's own install inputs, so the key can change without a file edit, e.g. when a different set of workspace members lands in the bundle. To force a reinstall for deployed checks, set `runner.cache.install.version` (a string or a safe integer) at the top level of `checkly.config.ts` — not per check — and change its value whenever the cache should be invalidated; deployed, scheduled checks pick up the change on the next `checkly deploy`. Unset or empty values leave the cache key unchanged, so a dynamic value such as `version: process.env.DEPENDENCY_CACHE_VERSION` is safe when the variable is not always set. For a one-off reinstall during an ad-hoc run, use the `--refresh-cache` flag on `checkly test`, `checkly pw-test`, `checkly trigger`, or `checkly checks run` instead.
 - If dependencies come from a private registry that Checkly's infrastructure cannot reach (for example an intranet-only Nexus mirror), list them in `bundle.packages.embed` in `checkly.config.ts` — a top-level section: `bundle: { packages: { embed: ['@acme/private-utils', 'legacy-private-pkg@2.1.0'] } }`. The CLI resolves the entries against the workspace-root lockfile (Yarn Classic v1 lockfiles are not supported), downloads their tarballs, verifies each tarball's integrity (recorded in the lockfile, or fetched from registry metadata for Yarn Berry), and ships them inside the code bundle so the runner can install them without reaching the registry. Applies to Playwright Check Suites only, not Browser or Multistep Checks.
   - Each entry is a package name (embeds every version found in the lockfile) or an exact `name@version` pin. Names may contain `*` wildcards (`@acme/*`; a single `*` never crosses `/`, while `**` does — `**` alone matches every package, and `**/utils` matches `utils` in any scope or none), and a `!` prefix turns an entry into an exclusion that subtracts from the entries before it — order matters: `['@acme/*', '!@acme/legacy']` embeds the scope except `@acme/legacy`. A selecting entry that matches nothing in the lockfile fails validation and blocks the deploy — do not add speculative names — and so does an entry whose only matches cannot be embedded (git/file/URL or integrity-less lockfile entries, which the runner must fetch itself); a `!` exclusion that matches nothing is a silent no-op, and a list that ends up selecting nothing overall only warns.
   - List every unreachable package by name, including private packages that only appear as transitive dependencies of other private packages — dependencies of listed packages are not embedded automatically.
@@ -57,7 +57,7 @@
 
 - Do not use `runtimeId` for Playwright Check Suites. Browser and Multistep Checks use `runtimeId`; Playwright Check Suites use project dependencies plus `engine`.
 - Omit `engine` unless the user explicitly asks to override the JavaScript engine or version.
-- If an engine override is needed, import `Engine` from `checkly/constructs` and use `Engine.node("24")` or `Engine.bun("1.3")`.
+- If an engine override is needed, import `Engine` from `checkly/constructs` and use `Engine.node("24")` or `Engine.bun("1.4")` (`Engine.bun("1")` follows the newest Bun 1.x available on the runner).
 - If no engine is configured or detected, Checkly defaults to Node.js 22. Node.js engine majors map to pinned patch versions: `22` -> `22.14.0`, `24` -> `24.13.1`, and `26` -> `26.2.0`.
 - For env vars Checkly exposes at runtime (e.g. `CHECKLY=1` for "am I running on Checkly?"), see `npx checkly skills configure environment`.
 

package/dist/ai-context/skills-command/references/configure-supporting-constructs.md

@@ -133,8 +133,8 @@ new Dashboard('example-dashboard', {
 ## Maintenance Window
 
 - Import the `MaintenanceWindow` construct from `checkly/constructs`.
-- Maintenance windows are used to pause checks during maintenance periods so no alerts are sent.
-- Checks are referenced by their tags in the `tags` property.
+- Maintenance windows pause checks (`tags` or `pauseAllChecks`) and/or silence their alerts while the checks keep running (`silenceAlertsTags` or `silenceAllAlerts`).
+- Set `timezone` (an IANA name such as `America/New_York`) so recurring windows keep their local time.
 
 **Reference:** https://www.checklyhq.com/docs/constructs/maintenance-window/
 
@@ -151,6 +151,10 @@ new MaintenanceWindow('example-maintenance-window', {
   repeatInterval: 1,
   repeatUnit: 'WEEK',
   repeatEndsAt: new Date('2025-08-01T00:00:00.000Z'),
+  timezone: 'America/New_York',
+  silenceAlertsTags: [
+    'app:webshop',
+  ],
 })
 ```
 

package/dist/ai-context/skills-command/references/configure-tcp-monitors.md

@@ -7,31 +7,22 @@
 **Reference:** https://www.checklyhq.com/docs/constructs/tcp-monitor/
 
 ```typescript
-import { AlertEscalationBuilder, Frequency, RetryStrategyBuilder, TcpAssertionBuilder, TcpMonitor } from 'checkly/constructs'
+import { Frequency, RetryStrategyBuilder, TcpAssertionBuilder, TcpMonitor } from 'checkly/constructs'
 
 new TcpMonitor('example-tcp-monitor', {
   name: 'Example TCP Monitor',
   degradedResponseTime: 5000,
   maxResponseTime: 5000,
-  activated: true,
   locations: [
     'eu-central-1',
     'eu-west-2',
   ],
   frequency: Frequency.EVERY_1H,
-  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
-    amount: 0,
-    interval: 5,
-  }, {
-    enabled: false,
-    percentage: 10,
-  }),
   retryStrategy: RetryStrategyBuilder.noRetries(),
   runParallel: true,
   request: {
     hostname: 'INSERT_HOSTNAME',
     port: 4242,
-    ipFamily: 'IPv4',
     assertions: [
       TcpAssertionBuilder.responseTime().lessThan(200),
       TcpAssertionBuilder.responseData().isEmpty(),

package/dist/ai-context/skills-command/references/configure-url-monitors.md

@@ -8,30 +8,21 @@
 **Reference:** https://www.checklyhq.com/docs/constructs/url-monitor/
 
 ```typescript
-import { AlertEscalationBuilder, Frequency, RetryStrategyBuilder, UrlAssertionBuilder, UrlMonitor } from 'checkly/constructs'
+import { Frequency, RetryStrategyBuilder, UrlAssertionBuilder, UrlMonitor } from 'checkly/constructs'
 
 new UrlMonitor('example-url-monitor', {
   name: 'Example URL Monitor',
-  activated: true,
   locations: [
     'eu-central-1',
     'eu-west-2',
   ],
   frequency: Frequency.EVERY_5M,
-  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
-    amount: 0,
-    interval: 5,
-  }, {
-    enabled: false,
-    percentage: 10,
-  }),
   retryStrategy: RetryStrategyBuilder.noRetries(),
   runParallel: true,
   degradedResponseTime: 5000,
   maxResponseTime: 20000,
   request: {
     url: 'INSERT_URL',
-    ipFamily: 'IPv4',
     assertions: [
       UrlAssertionBuilder.statusCode().equals(200),
     ],

package/dist/ai-context/skills-command/references/configure.md

@@ -47,6 +47,7 @@ import { Frequency } from 'checkly/constructs'
 export default defineConfig({
   projectName: "Production Monitoring Suite",
   logicalId: "prod-monitoring-2025",
+  // Must be this repo's own remote (`git remote get-url origin` as https). Never copy this example value.
   repoUrl: "https://github.com/acme/monitoring",
   checks: {
     activated: true,
@@ -147,6 +148,8 @@ npx checkly account plan --output json
 
 This returns your exact entitlements and available locations. Use only locations where `available` is `true` in the `locations.all` array. A disabled feature may include an `upgradeUrl`; share it only when present. Without one, the feature is unavailable.
 
+Give every check at least one entry in `locations` or `privateLocations`, on the check, on its group, or as a default in `checks.locations` or `checks.privateLocations` of `checkly.config.ts`. A deployed check without any runs in a location chosen by Checkly, and `deploy` and `validate` warn about it.
+
 Run `npx checkly skills manage plan` for the full reference.
 
 ## Testing and Debugging
@@ -156,7 +159,14 @@ Run `npx checkly skills manage plan` for the full reference.
 ## Deploying
 
 - Deploy checks using the `npx checkly deploy` command. Use `--output` to see the created, updated, and deleted resources. Use `--verbose` to also include each resource's name and physical ID (UUID), which is useful for programmatically referencing deployed resources (e.g. `npx checkly checks get <id>`).
-- Use `--preview` to see what a deploy would change without applying it.
+- A deploy is planned: Checkly compares every resource with what is deployed, property by property, the deploy then writes only the resources that differ, and it refuses to run if the account changed after the plan was made. `--no-plan` deploys without a plan: every resource the project declares is written, and edits made outside the project are overwritten without being reported.
+- A resource Checkly has no baseline for (for example every resource already deployed on a project's first planned `checkly deploy` or on the first after any deploy with `--no-plan`, one added with `checkly import`, or one whose stored baseline a Checkly update made unusable) is written once to set it. When nothing differs the plan lists it with the marker `=` after the resources it changes, counts it as `to set a baseline` rather than `to update`, and a note under the overview explains the marker; the `confirmation_required` envelope names it `Set a baseline for <Type>: <id>`. When something differs it is an ordinary update with its diff. Such an entry carries `basis: "live"` in the machine-readable plan, and its list of changes is not exhaustive: a value set only in Checkly, on a property the code does not set, may be reset without being shown. Later deploys show and write only what changed.
+- Use `--preview` to see which resources a deploy would create, update or delete, without applying it. It also shows the resources the deploy would keep as they are and a diff of each updated resource's construct as deployed against as in code, and a plain interactive `checkly deploy` prints that same preview before asking the user to apply the changes or cancel. The machine-readable forms (`--dry-run`, and the `confirmation_required` envelope) additionally carry the individual properties that would change; with `--no-plan` they list the deploy's options and the resources it would delete.
+- When the preview shows a resource that was edited outside the project (in the web app or through the API), an interactive `checkly deploy` offers a third choice next to apply and cancel: update the code with the values from Checkly and deploy nothing. It exists only in a terminal; there is no flag for it, and the `confirmation_required` envelope is unchanged.
+  - It rewrites literal values (strings, numbers, booleans, and arrays or objects of those; a multi-line string over a template literal is written as a template literal) and the helper-spelled properties `frequency` (`Frequency.EVERY_5M`), `retryStrategy` (`RetryStrategyBuilder`), `alertEscalationPolicy` (`AlertEscalationBuilder`) and `assertions` (the class's assertion builder) inside the `new SomeConstruct('id', { … })` call, adds a helper's import when the file lacks it, and leaves the rest of the file untouched. Covered: checks and check groups (including `runtimeId` on runtime checks and groups, the `request` of every check and monitor type, `intent` on every check and monitor that takes one, `sslCheckDomain` and `aiAutoRepairEnabled` on browser checks, and `aiAutoRepairEnabled` on multistep checks), alert channels of every type, private locations, dashboards, maintenance windows (`repeatInterval` and `repeatUnit` together), status pages (v2 and v3, each theme colour under an existing `themeColors.light`/`.dark`), status page services, v3 components and automation rules.
+  - It lists everything it could not update with the reason: references to other resources, secrets (a credential such as a webhook URL or API key is never written), scripts, a dashboard's `customCSS`, an incident trigger, an alert channel's type or a webhook-based channel's fixed type and method, Telegram's packed template, a helper call holding a variable, a check moved to the global alert policy, which needs `alertEscalationPolicy` removed by hand.
+- Use `--prune-unmanaged-relations` to also delete the alert channel subscriptions and private location assignments on this project's checks and groups that the project does not manage. Without it they are only reported. Not available with `--no-plan`.
+- Use `--fail-on-drift` (or `CHECKLY_FAIL_ON_DRIFT=1`) to deploy nothing and exit 1 when the deploy would overwrite a resource changed or deleted in Checkly since the last planned deploy, for example in CI with `--force`. `checkly deploy --preview --fail-on-drift` checks for such changes without deploying; with `--dry-run` the flag is ignored and the envelope reports them. A resource without a baseline cannot be checked and only gets a warning. Not available with `--no-plan`.
 
 ### Deleted resources
 
@@ -166,16 +176,18 @@ This matters when the local project isn't the whole picture — a partial checko
 
 ### Confirmation
 
-`deploy` is a write command: without `--force` it returns exit code 2 and a `confirmation_required` envelope. Present its `changes` to the user and run the `confirmCommand` verbatim only after they approve.
+`deploy` is a write command: without `--force` it returns exit code 3 and a `confirmation_required` envelope. Present its `changes` to the user and run the `confirmCommand` verbatim only after they approve. The one exception is a `checkly deploy` whose plan has nothing to create, update, delete or detach and no relation to prune: it asks for no confirmation, prints `No changes.`, and completes with exit code 0. That run still records the deployment. It schedules no checks unless `--schedule-on-deploy --schedule-on-deploy-scope=all` is passed: a deploy schedules checks only with `--schedule-on-deploy`, and then only the checks it changed; with `all`, every check, unless there are more of them than the scheduling threshold allows (`--schedule-on-deploy-threshold`, by default set by Checkly), leaving out the checks that run more often than the minimum frequency for deploys (`--schedule-on-deploy-min-frequency`, by default set by Checkly). Its last line says whether it scheduled any.
+
+The confirmation happens **after** the project has been parsed. Unless the run passed `--preserve-resources`, Checkly has also been asked what the deploy would delete, and every resource to be deleted is named in `changes`. Show the user the deletions before you run the `confirmCommand`. Nothing has been written or uploaded at that point.
 
-That confirmation happens **before the project is parsed**, so it cannot tell you which resources would be deleted — its `changes` only warn that deletion is possible. There is a second, itemised guard that lists each doomed resource by name, but it is skipped by `--force`, and `--force` is exactly what the `confirmCommand` carries. **An agent following the confirmation protocol never sees that list.** It is a prompt for humans deploying by hand.
+With a plan, `changes` names every resource the deploy touches, and the envelope carries a `preview` object with the machine-readable plan — one entry per resource, with the properties that would change. If Checkly could not provide a plan, the run says so and continues as one with `--no-plan`: the envelope then has no `preview` object. The envelope's `preview.planToken` identifies the plan, and the `confirmCommand` carries it as `--plan-token`. The confirming run therefore applies that plan against the same Checkly state and aborts if the account moved in between; it does not pin your local code, so an edit you make between the two runs is previewed again and deployed without a second prompt (see "Commands that pin a resolved target" in the `communicate` skill).
 
-So when resources may have been removed from the code, don't rely on the confirmation to surface it — preview first:
+To look without confirming anything:
 
 ```bash
 npx checkly deploy --preview
 ```
 
-This is a dry run: nothing is applied and nothing is confirmed. It prints the resources that would be created, updated, and deleted (add `--verbose` for names and IDs). Show the user what would be deleted, and only then deploy.
+Nothing is applied and nothing is confirmed. It prints the resources that would be created, updated, deleted and kept, and the plan token (add `--verbose` for names and IDs). `--dry-run` does the same for machine consumption: it prints the `dry_run` envelope, with the same `preview` object, and exits 0. With `--no-plan`, neither form has a plan to show: `--preview` lists every existing resource as an update, and the `--dry-run` envelope has no `preview` object.
 
 Run `npx checkly skills communicate` for the full protocol.