@chainpatrol/cli 0.4.0 → 0.4.1

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # @chainpatrol/cli
 
+## 0.4.1
+
+### Patch Changes
+
+- 9126b45: Split the `reviewing.backlog` healthcheck into reviewable vs. total pending so the count matches the reviewing page in the app. The endpoint now reports `pendingProposals` (total), `reviewableProposals` (the subset the UI shows by default — assets not watchlisted, or reports from a customer), and `watchlistedHiddenProposals` (delta). Severity grades on the reviewable count; a non-zero watchlisted bucket surfaces as a warn-level finding. The bundled CLI skill is updated to document the new shape.
+- fb0b846: Split the reviewing healthchecks along the operational divide between "Needs Review" (high-priority queue reviewers act on) and "Watchlisted" (intentionally deferred bucket):
+
+  - `reviewing.backlog` and `reviewing.old-proposals` now grade the Needs-Review bucket only — assets not on a watchlist, or reports submitted by a customer. Their counts now match what the reviewing page in the app shows by default.
+  - Two new checks cover the Watchlisted bucket as separate first-class signals: `reviewing.watchlist-backlog` (pile-up of watchlisted pending proposals) and `reviewing.watchlist-old` (watchlisted proposals deferred too long). Severity for both is **capped at warn** — watchlist cleanup matters but should never block on the same SLA as Needs Review.
+
+  The CLI skill is updated to spell out the distinction so a healthcheck report groups findings under the right bucket.
+
 ## 0.4.0
 
 ### Minor Changes

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

@@ -323,16 +323,41 @@ 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\`,
-\`reviewing.old-proposals\`, \`takedowns.stale-in-progress\`.
+\`reviewing.old-proposals\`, \`reviewing.watchlist-backlog\`,
+\`reviewing.watchlist-old\`, \`takedowns.stale-in-progress\`.
+
+### Pending proposals: "Needs Review" vs "Watchlisted"
+
+PENDING proposals split into two operationally distinct buckets, and we
+grade them with separate checks:
+
+- **Needs Review** \u2014 pending proposals the reviewing UI shows by default
+  (\`excludeWatchlisted=true\`): assets that are NOT on a watchlist, OR
+  reports submitted by a customer (those stay visible even when the asset
+  is watchlisted). This is the actionable queue reviewers work from, so
+  pile-ups and old items here are high-priority signals (\`fail\` severity
+  is reachable).
+- **Watchlisted** \u2014 pending proposals on watchlisted assets (excluding
+  customer-reported reports). The reviewing UI hides these by default
+  because watchlisting is the act of intentionally deferring an asset.
+  Pile-ups and aged items here are worth surfacing as cleanup work, but
+  severity is **capped at warn** so they never block on the same SLA as
+  Needs Review. When reporting findings, treat these as lower-priority.
 
 Implemented checks today:
 
 - **detections.silent-configs** \u2014 equivalent to \`detections healthcheck\`,
   exposed under the uniform shape.
-- **reviewing.backlog** \u2014 counts proposals in PENDING review state and grades
+- **reviewing.backlog** \u2014 counts Needs Review pending proposals and grades
   severity against per-org thresholds (default warn=50, fail=100).
-- **reviewing.old-proposals** \u2014 counts proposals older than the warn / fail
-  age thresholds (default 7 / 14 days) and lists the oldest offenders.
+- **reviewing.old-proposals** \u2014 counts Needs Review proposals older than
+  the warn / fail age thresholds (default 7 / 14 days) and lists the
+  oldest offenders.
+- **reviewing.watchlist-backlog** \u2014 counts watchlisted pending proposals
+  (default warn=200). Severity capped at warn.
+- **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.stale-in-progress** \u2014 counts takedowns sitting in IN_PROGRESS
   past the staleness threshold (default 7 days) and lists the oldest.
 
@@ -644,7 +669,23 @@ executed. For soft drops (still producing results but below baseline),
 
 ### Reviewing
 
-#### Pile Up / Backlog of Unreviewed Proposals
+PENDING proposals split into two operationally distinct buckets:
+
+- **Needs Review** \u2014 assets not on a watchlist, or reports submitted by a
+  customer. This is the reviewing UI's default view (\`excludeWatchlisted=true\`)
+  and the actionable queue reviewers work from. Pile-ups and aged items
+  here are high priority \u2014 \`fail\` severity is reachable.
+- **Watchlisted** \u2014 pending proposals on watchlisted assets (excluding
+  customer-reported reports). The UI hides these by default because
+  watchlisting is the act of intentionally deferring the asset. Pile-ups
+  and aged items here are worth surfacing as cleanup work but **severity
+  is capped at warn** \u2014 they should never block on the same SLA as Needs
+  Review.
+
+Each bucket has its own pile-up and age check, so you can grade them
+independently and tune thresholds without one drowning the other.
+
+#### Pile Up / Backlog of Needs-Review Proposals
 
 Too many proposals waiting in review. For most organizations this is over 100
 reports, but really the threshold is relative to the average number of
@@ -652,30 +693,50 @@ confirmed threats per week. Example: if an org only adds 5 blocked threats per
 week, then a 7-day backlog of even 10 proposals is a really big deal.
 
 **Run via CLI:** **Implemented as \`healthchecks run reviewing.backlog\`.**
-The endpoint counts proposals in PENDING review state and grades severity
+The endpoint counts the **Needs Review** subset only (assets not
+watchlisted, or reports marked \`reportedByCustomer\`) and grades severity
 against per-org thresholds (default warn=50, fail=100; override with
-\`--warn-threshold\` / \`--fail-threshold\` via the run payload). For raw
-counts plus SLA / age breakdowns, \`chainpatrol --json queues snapshot --org <slug>\`
-remains useful and exposes \`reviewQueue.totalPendingProposals\` and
-\`reviewQueue.distinctReports\`. Compare against the org's typical weekly
-throughput (use \`metrics summary --this-week\` for that baseline) \u2014 a
-backlog that exceeds a week of typical confirmed-threat volume is a finding
-regardless of the absolute number.
-
-#### Really Old Proposals
-
-Any proposal waiting for review longer than 14 days is a sign something has
-gone wrong. Even complex investigations rarely take longer than this. Except
-for rare cases, these should be rejected or approved to prevent a backlog
-from building.
+\`--warn-threshold\` / \`--fail-threshold\` via the run payload). This is
+the number the reviewing page in the app shows by default, so the
+healthcheck output matches what reviewers see.
+
+For raw counts plus SLA / age breakdowns,
+\`chainpatrol --json queues snapshot --org <slug>\` remains useful and
+exposes \`reviewQueue.totalPendingProposals\` and
+\`reviewQueue.distinctReports\` (note: \`queues snapshot\` does NOT apply
+the watchlist filter, so its number is the sum of Needs Review +
+Watchlisted). Compare against the org's typical weekly throughput
+(use \`metrics summary --this-week\` for that baseline) \u2014 a backlog that
+exceeds a week of typical confirmed-threat volume is a finding regardless
+of the absolute number.
+
+#### Really Old Needs-Review Proposals
+
+Any Needs-Review proposal waiting longer than 14 days is a sign something
+has gone wrong. Even complex investigations rarely take longer than this.
+Except for rare cases, these should be rejected or approved to prevent a
+backlog from building.
 
 **Run via CLI:** **Implemented as \`healthchecks run reviewing.old-proposals\`.**
-The endpoint counts pending proposals older than the warn / fail age
+The endpoint counts Needs-Review proposals older than the warn / fail age
 thresholds (default 7 / 14 days) and lists the oldest offenders in
 \`findings\`. \`queues snapshot\` (\`reviewQueue.ageBuckets.gte168h\`) still
 works as a raw view, and \`reviewQueue.slaBuckets.breached\` captures the
 strictest SLA breaches separately \u2014 any non-zero value is worth raising.
 
+#### Watchlist Pile-Up / Old Watchlisted Proposals
+
+Watchlisted-pending proposals are deferred on purpose, but they shouldn't
+grow unbounded \u2014 a huge pile or very-old items signal that the watchlist
+needs a cleanup pass. These don't block on the same SLA as Needs Review.
+
+**Run via CLI:** **Implemented as \`healthchecks run reviewing.watchlist-backlog\`**
+(pile-up count, default warn=200) and
+**\`healthchecks run reviewing.watchlist-old\`** (default warn-age 30
+days). Both cap severity at warn. When reporting findings during an org
+healthcheck, group them under "watchlist cleanup" rather than mixing with
+Needs-Review findings \u2014 they're operationally different concerns.
+
 #### Spike in Auto Approved Reports
 
 If suddenly a lot of proposals in an org are being approved by automation,

package/dist/cli.js

@@ -13,7 +13,7 @@ import {
   getCliVersion,
   isSkillInstalled,
   readInstalledSkillVersion
-} from "./chunk-S65NM7FF.js";
+} from "./chunk-F4GU6AII.js";
 import "./chunk-IUZB3DQW.js";
 import {
   DateTime
@@ -1095,12 +1095,12 @@ async function main() {
     case "setup":
     case "install":
     case "i": {
-      const { setupSkill } = await import("./setup-skill-Z5RVCWCU.js");
+      const { setupSkill } = await import("./setup-skill-2SEVH3M6.js");
       setupSkill({ json: jsonMode });
       break;
     }
     case "uninstall": {
-      const { uninstallSkill } = await import("./setup-skill-Z5RVCWCU.js");
+      const { uninstallSkill } = await import("./setup-skill-2SEVH3M6.js");
       uninstallSkill({ json: jsonMode });
       break;
     }

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

@@ -6,7 +6,7 @@ import {
   readInstalledSkillVersion,
   setupSkill,
   uninstallSkill
-} from "./chunk-S65NM7FF.js";
+} from "./chunk-F4GU6AII.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.0",
+  "version": "0.4.1",
   "license": "UNLICENSED",
   "homepage": "https://chainpatrol.com/docs/cli",
   "keywords": [