@chainpatrol/cli 0.4.1 → 0.5.0

package/CHANGELOG.md

@@ -1,5 +1,23 @@
 # @chainpatrol/cli
 
+## 0.5.0
+
+### Minor Changes
+
+- f8d9454: Add five new healthchecks covering the takedown pipeline and asset liveness, expanding the runnable surface for `chainpatrol healthchecks run`:
+
+  - **`takedowns.todo-volume`** — counts takedowns sitting in TODO. Default warn=50, fail=100. Catches automation gaps on new threat surfaces or manual-filing capacity issues.
+  - **`takedowns.in-progress-volume`** — counts takedowns currently IN*PROGRESS regardless of age. Default warn=30, fail=75. Complements `takedowns.stale-in-progress` (age-based) by catching submission-format / vendor-side issues \_before* items go stale.
+  - **`takedowns.cancelled-count`** — counts transitions into CANCELLED from the `TakedownEvent` log over a rolling window. Default 7d / warn=3 / fail=10. Replaces the placeholder `takedowns.cancelled-rate` registry entry. Uses the event log rather than `Takedown.updatedAt` so the cancellation date is correct even if the takedown has since been edited.
+  - **`takedowns.automation-off`** — flags orgs with takedown service enabled but `isAutomatedTakedownsActive` off for too long. Default warn=30d, fail=60d. Age is derived from the most recent `SERVICES_AUTOMATED_TAKEDOWNS_UPDATED` `OrganizationEvent`, falling back to `Organization.updatedAt`. Orgs with takedown service entirely disabled are skipped.
+  - **`assets.dead-asset-spike`** — compares `DETECTED_AS_DEAD` events in the current window against the prior baseline rate; warns on a multiplier exceeding the threshold (default 24h vs 7d, ×2 warn / ×4 fail) once the current count clears the `minSpikeCount` floor. Catches liveness-checker regressions after platform changes.
+
+  The bundled CLI skill gets a rewritten **Takedowns** section covering all four takedown checks and a new top-level **Assets** section covering `dead-asset-spike` plus guidance on the still-unimplemented `assets.dead-but-alive` / `assets.alive-but-marked-dead` (which require live HTTP probes and are not a fit for synchronous healthchecks).
+
+  The public `HealthcheckResult.category` enum gains `"assets"`. `observed` and `threshold` records now also accept booleans and null (for fields like `automatedTakedownsActive` and the nullable `ratio` on the spike check).
+
+  `HealthcheckResult` also gains an `appUrl` field (string or null) that deep-links to the relevant filtered admin page in the web app. For example, `takedowns.stale-in-progress` returns `https://app.chainpatrol.io/admin/<slug>/takedowns?takedownStatus=IN_PROGRESS&sortBy=oldest` and `reviewing.backlog` returns `https://app.chainpatrol.io/admin/<slug>/review?excludeWatchlisted=true`. The CLI prints `View in app: <url>` after each result. Checks without a sensible filtered view (`detections.silent-configs`, `assets.dead-asset-spike`) return `null`. The base URL respects `BETTER_AUTH_URL` and falls back to `https://app.chainpatrol.io`.
+
 ## 0.4.1
 
 ### Patch Changes

package/dist/{chunk-F4GU6AII.js → chunk-BSK4YHFA.js}

@@ -321,10 +321,13 @@ chainpatrol --json healthchecks run reviewing.backlog --org <slug>
 chainpatrol --json healthchecks run --all --org <slug>
 \`\`\`
 
-Each implemented check has a stable id of the form \`category.name\`, e.g.
-\`detections.silent-configs\`, \`reviewing.backlog\`,
+Each implemented check has a stable id of the form \`category.name\`. Implemented
+ids today: \`detections.silent-configs\`, \`reviewing.backlog\`,
 \`reviewing.old-proposals\`, \`reviewing.watchlist-backlog\`,
-\`reviewing.watchlist-old\`, \`takedowns.stale-in-progress\`.
+\`reviewing.watchlist-old\`, \`takedowns.todo-volume\`,
+\`takedowns.in-progress-volume\`, \`takedowns.stale-in-progress\`,
+\`takedowns.cancelled-count\`, \`takedowns.automation-off\`,
+\`assets.dead-asset-spike\`.
 
 ### Pending proposals: "Needs Review" vs "Watchlisted"
 
@@ -344,6 +347,15 @@ grade them with separate checks:
   severity is **capped at warn** so they never block on the same SLA as
   Needs Review. When reporting findings, treat these as lower-priority.
 
+Each healthcheck result includes an \`appUrl\` field (string or null) that
+deep-links to the relevant filtered admin page in the web app \u2014 e.g. the
+takedowns page filtered to IN_PROGRESS for \`takedowns.stale-in-progress\`,
+or the review page filtered to oldest pending for \`reviewing.old-proposals\`.
+**When reporting a non-OK healthcheck to the user, always surface the
+\`appUrl\` so they can jump straight to the right view.** Some checks
+(\`detections.silent-configs\`, \`assets.dead-asset-spike\`) emit \`null\`
+because no filterable list page exists for that signal yet.
+
 Implemented checks today:
 
 - **detections.silent-configs** \u2014 equivalent to \`detections healthcheck\`,
@@ -358,8 +370,27 @@ Implemented checks today:
 - **reviewing.watchlist-old** \u2014 counts watchlisted pending proposals older
   than the warn-age threshold (default 30 days) and lists the oldest.
   Severity capped at warn.
+- **takedowns.todo-volume** \u2014 counts takedowns in TODO (default warn=50,
+  fail=100). Pile-ups here usually mean an automation gap on a new threat
+  surface, or manual-filing capacity issues.
+- **takedowns.in-progress-volume** \u2014 counts takedowns currently IN_PROGRESS
+  regardless of age (default warn=30, fail=75). Complements
+  \`stale-in-progress\` \u2014 a high count signals vendor-side or
+  submission-format problems even before items go stale.
 - **takedowns.stale-in-progress** \u2014 counts takedowns sitting in IN_PROGRESS
   past the staleness threshold (default 7 days) and lists the oldest.
+- **takedowns.cancelled-count** \u2014 counts CANCELLED transitions from the
+  TakedownEvent log over a rolling window (default 7d, warn=3, fail=10).
+  Cancellations should be rare; a spike usually means a proposal-funnel
+  quality problem or misuse of the CANCELLED status.
+- **takedowns.automation-off** \u2014 flags orgs with takedown service enabled
+  but \`isAutomatedTakedownsActive\` off for too long (default warn=30d,
+  fail=60d). Skipped for orgs with takedown service entirely disabled.
+- **assets.dead-asset-spike** \u2014 compares DEAD-detection events in the
+  current window against the prior baseline rate; warns on a multiplier
+  exceeding the threshold (default 24h vs 7d, \xD72 warn / \xD74 fail) once the
+  current count clears the \`minSpikeCount\` floor. Catches liveness-checker
+  regressions after platform changes.
 
 The following checks are listed by \`healthchecks list\` (\`implemented: false\`)
 but **not yet implemented on the backend** \u2014 when the agent surfaces them in
@@ -373,8 +404,11 @@ a healthcheck report, mark them explicitly as "manual check, no API yet":
   human approvers in the review history. Use \`metrics breakdown\` as a proxy.
 - **blocklisting.gsb-cancelled-rate** \u2014 Google Safe Browsing submission state
   is not yet exposed in the public API.
-- **takedowns.todo-volume** / **takedowns.cancelled-rate** /
-  **takedowns.automation-off** \u2014 the underlying read paths are not yet exposed.
+- **assets.dead-but-alive** / **assets.alive-but-marked-dead** \u2014 require live
+  HTTP probes against asset URLs, which is not a synchronous-healthcheck
+  shape. Until a dedicated probe command exists, sample a handful manually
+  from \`assets list --status DEAD\` (or ALIVE) and verify in a browser. Notify
+  ChainPatrol engineering if the liveness checker looks miscalibrated.
 
 When the user asks to "run a healthcheck on org X", the canonical command is:
 
@@ -775,19 +809,23 @@ exposed in the public API, this remains a manual / engineering-team check.
 
 ### Takedowns
 
+The takedown pipeline has three stages \u2014 TODO (queued, not yet filed),
+IN_PROGRESS (filed, waiting on vendor / customer / refile), and a terminal
+state (COMPLETED or CANCELLED). Healthchecks cover pile-ups at each stage,
+plus quality/configuration issues.
+
 #### Too Many Takedowns in ToDo
 
 Can mean a gap in automated takedowns not being implemented for some new area
 of threats. It can also mean the areas that require manual takedowns are
 being missed by the takedown team.
 
-**Run via CLI:** **Not yet implemented as a healthcheck endpoint.** Listed
-in \`healthchecks list\` as \`takedowns.todo-volume\` with
-\`implemented: false\` (needs a per-org throughput baseline). As an interim
-signal, \`chainpatrol --json queues snapshot --org <slug>\` returns
-\`takedownQueue.totalOpen\` and breakdowns by status; a persistently large
-ToDo bucket relative to the org's typical takedown rate (use
-\`metrics summary\` for that baseline) is the finding.
+**Run via CLI:** **Implemented as \`healthchecks run takedowns.todo-volume\`.**
+Counts takedowns sitting in TODO (default warn=50, fail=100). For raw
+breakdowns by type, cross-reference with
+\`chainpatrol --json metrics breakdown --org <slug> --by assetType\` \u2014
+items piled up on a specific platform usually point at an automation
+gap there.
 
 #### Too Many Takedowns In Progress
 
@@ -795,12 +833,16 @@ Typically means something is wrong with the submission itself. The takedown
 may need to be resubmitted, the vendor asked for more evidence, or we may
 have submitted it in the wrong place.
 
-**Run via CLI:** **Implemented as \`healthchecks run takedowns.stale-in-progress\`.**
-The endpoint counts takedowns sitting in IN_PROGRESS past the staleness
-threshold (default 7 days) and lists the oldest offenders in \`findings\`.
-\`queues snapshot\` (\`takedownQueue.staleInProgress\`) still works as a raw
-view. Any non-zero value is worth investigating; a growing number across
-snapshots strongly suggests a vendor-side or submission-format problem.
+**Run via CLI:** Two checks, complementary:
+
+- **\`healthchecks run takedowns.in-progress-volume\`** \u2014 counts all
+  IN_PROGRESS takedowns regardless of age (default warn=30, fail=75).
+  Catches a vendor-side or submission-format problem before items go
+  stale.
+- **\`healthchecks run takedowns.stale-in-progress\`** \u2014 counts IN_PROGRESS
+  takedowns past a staleness threshold (default 7 days), lists the oldest
+  offenders. Any non-zero value is worth investigating; a growing count
+  across snapshots strongly suggests vendor-side or format issues.
 
 #### Too Many Cancelled Takedowns
 
@@ -809,14 +851,13 @@ do this takedown" for some reason. Cases like adding an item to the blocklist
 when it's already taken down are treated as completed, not cancelled. So even
 3 cancelled takedowns in a 7-day period is too many.
 
-**Run via CLI:** **Not yet implemented as a healthcheck endpoint.** Listed
-in \`healthchecks list\` as \`takedowns.cancelled-rate\` with
-\`implemented: false\` (public API does not yet expose CANCELLED takedown
-counts over a rolling window). As an interim signal, use
-\`chainpatrol --json metrics breakdown --org <slug> --by day --this-week\`
-and compare \`takedownsFiled\` vs \`takedownsCompleted\` for a sudden
-divergence \u2014 a widening gap with no In-Progress growth often shows up as
-cancellations.
+**Run via CLI:** **Implemented as \`healthchecks run takedowns.cancelled-count\`.**
+Counts transitions into the CANCELLED status from the TakedownEvent log
+within the lookback window (default 7 days, warn=3, fail=10). The check
+uses the event log rather than \`Takedown.updatedAt\` so it correctly
+attributes the cancellation date even if the takedown has since been
+edited. A spike usually means a quality problem in the proposal funnel
+or the CANCELLED status being used as a catch-all.
 
 #### Automated Takedowns Turned Off for Over 30 Days
 
@@ -824,12 +865,56 @@ Automated takedowns should be on by default for nearly every organization.
 Any issue that would make you want to turn off automated takedowns should be
 resolved within 30 days.
 
-**Run via CLI:** **Not yet implemented as a healthcheck endpoint.** Listed
-in \`healthchecks list\` as \`takedowns.automation-off\` with
-\`implemented: false\` (public API does not yet expose automated-takedown
-enablement state). Check this manually with the org's takedown automation
-settings; the CLI's role here is mostly to highlight stale state in
-\`queues snapshot\` so you know to ask.
+**Run via CLI:** **Implemented as \`healthchecks run takedowns.automation-off\`.**
+Checks \`Organization.isAutomatedTakedownsActive\` and derives the
+off-duration from the most recent \`SERVICES_AUTOMATED_TAKEDOWNS_UPDATED\`
+entry in \`OrganizationEvent\` (default warn 30 days, fail 60 days). Orgs
+with takedown service entirely disabled (\`isTakedownsActive=0\`) are
+skipped \u2014 automation being off is implied in that case.
+
+### Assets
+
+Healthchecks on the asset model \u2014 specifically asset liveness state, which
+the takedown team depends on for follow-up.
+
+#### Spike in Recently Dead Assets
+
+A sudden spike in DEAD detections can be a good signal (takedowns or platform
+moderation working) but it can also mean the liveness checker is
+misclassifying assets after a platform change, captcha rollout, or anti-bot
+update. If many assets become dead at once, sample a few manually.
+
+**Run via CLI:** **Implemented as \`healthchecks run assets.dead-asset-spike\`.**
+Compares \`DETECTED_AS_DEAD\` events in the current window (default 24h)
+against the baseline rate from the prior \`baselineDays\` (default 7d).
+Severity fires only when the current count clears \`minSpikeCount\` (default
+10) AND exceeds the multiplier (default warn \xD72, fail \xD74). The
+\`minSpikeCount\` floor suppresses noise on orgs with near-zero baseline
+activity. When this fires, pull a sample of recent DEAD assets, verify a
+few in a browser, and notify ChainPatrol engineering if the sample is
+clearly still live.
+
+#### Assets Marked Dead but Still Online / Assets Not Marked Dead Even Though They Are Down
+
+These two opposite failure modes are **not implemented as healthchecks**
+(listed as \`assets.dead-but-alive\` and \`assets.alive-but-marked-dead\` with
+\`implemented: false\`). Both require live HTTP probes against asset URLs,
+which is not a synchronous-healthcheck shape.
+
+Until a dedicated probe command exists:
+
+- For "marked dead but still alive": sample a handful of recently-DEAD
+  assets, open them in a browser, and watch for any that load. Common
+  causes: bot protection, geo-blocking, rate limits, or liveness logic
+  that does not handle the asset type correctly.
+- For "alive but marked dead": after a known takedown event, sample
+  assets that *should* be dead but are still marked alive. Common causes:
+  cached responses, soft-404 pages, parked-domain redirects, platform
+  suspension pages still returning 200.
+
+In both cases, if liveness looks miscalibrated for a class of assets,
+notify ChainPatrol engineering \u2014 the checker likely needs a tuning pass for
+that platform.
 `;
 }
 function getBundledSkillVersion() {

package/dist/cli.js

@@ -13,7 +13,7 @@ import {
   getCliVersion,
   isSkillInstalled,
   readInstalledSkillVersion
-} from "./chunk-F4GU6AII.js";
+} from "./chunk-BSK4YHFA.js";
 import "./chunk-IUZB3DQW.js";
 import {
   DateTime
@@ -1049,7 +1049,7 @@ async function main() {
           thresholds.minResults = cli.flags.minResults;
         if (cli.flags.lookbackHours !== void 0)
           thresholds.lookbackHours = cli.flags.lookbackHours;
-        const { runHealthchecksRun } = await import("./run-7THXM7GF.js");
+        const { runHealthchecksRun } = await import("./run-64SBCL4R.js");
         await runHealthchecksRun({
           org,
           id: action,
@@ -1095,12 +1095,12 @@ async function main() {
     case "setup":
     case "install":
     case "i": {
-      const { setupSkill } = await import("./setup-skill-2SEVH3M6.js");
+      const { setupSkill } = await import("./setup-skill-NQIZBJMR.js");
       setupSkill({ json: jsonMode });
       break;
     }
     case "uninstall": {
-      const { uninstallSkill } = await import("./setup-skill-2SEVH3M6.js");
+      const { uninstallSkill } = await import("./setup-skill-NQIZBJMR.js");
       uninstallSkill({ json: jsonMode });
       break;
     }

package/dist/{run-7THXM7GF.js → run-64SBCL4R.js}

@@ -27,7 +27,12 @@ function buildPayload(entry, org, thresholds) {
     "failThreshold",
     "warnAgeHours",
     "failAgeHours",
-    "staleThresholdHours"
+    "staleThresholdHours",
+    "windowHours",
+    "baselineDays",
+    "warnMultiplier",
+    "failMultiplier",
+    "minSpikeCount"
   ]);
   for (const [key, value] of Object.entries(thresholds)) {
     if (allowedKeys.has(key)) {
@@ -150,6 +155,9 @@ async function runHealthchecksRun(options) {
         if (entry.result.suggestedAction) {
           lines.push(`- Suggested action: ${entry.result.suggestedAction}`);
         }
+        if (entry.result.appUrl) {
+          lines.push(`- View in app: ${entry.result.appUrl}`);
+        }
         return lines.join("\n");
       }),
       ...errors.map((entry) => `## ${entry.entry.id} \u2014 ERROR
@@ -194,6 +202,10 @@ async function runHealthchecksRun(options) {
           console.log(`Suggested action for ${entry.result.id}:`);
           console.log(`  ${entry.result.suggestedAction}`);
         }
+        if (entry.result.appUrl) {
+          console.log("");
+          console.log(`View in app: ${entry.result.appUrl}`);
+        }
       }
     }
   });

package/dist/{setup-skill-2SEVH3M6.js → setup-skill-NQIZBJMR.js}

@@ -6,7 +6,7 @@ import {
   readInstalledSkillVersion,
   setupSkill,
   uninstallSkill
-} from "./chunk-F4GU6AII.js";
+} from "./chunk-BSK4YHFA.js";
 import "./chunk-IUZB3DQW.js";
 export {
   getBundledSkillContent,

package/package.json

@@ -2,7 +2,7 @@
   "name": "@chainpatrol/cli",
   "description": "The official ChainPatrol CLI — terminal interface for threat detection",
   "author": "Umar Ahmed <umar@chainpatrol.io>",
-  "version": "0.4.1",
+  "version": "0.5.0",
   "license": "UNLICENSED",
   "homepage": "https://chainpatrol.com/docs/cli",
   "keywords": [