@chainpatrol/cli 0.4.0 → 0.5.0

package/CHANGELOG.md

@@ -1,5 +1,35 @@
 # @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
+
+- 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-BSK4YHFA.js}

@@ -321,20 +321,76 @@ 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\`,
-\`reviewing.old-proposals\`, \`takedowns.stale-in-progress\`.
+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.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"
+
+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.
+
+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\`,
   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.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
@@ -348,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:
 
@@ -644,7 +703,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 +727,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,
@@ -714,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
 
@@ -734,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
 
@@ -748,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
 
@@ -763,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-S65NM7FF.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-Z5RVCWCU.js");
+      const { setupSkill } = await import("./setup-skill-NQIZBJMR.js");
       setupSkill({ json: jsonMode });
       break;
     }
     case "uninstall": {
-      const { uninstallSkill } = await import("./setup-skill-Z5RVCWCU.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-Z5RVCWCU.js → setup-skill-NQIZBJMR.js}

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