Reduce supply chain risk posed by plannator

[rooterkyberian]

Plannator is great, been using it actively. Filing this because I want to keep using it confidently.

Problem

The two most common install methods force installing the latest released version with no pinning:

• curl -fsSL https://plannotator.ai/install.sh | bash - always pulls latest, no way to pin a reviewed version (hook README)
• Claude Code /plugin marketplace add + /plugin install - installs whatever's current, prompts to update everytime when UI screen pops up

(The Pi npm path pi install npm:@plannotator/pi-extension goes through npm and supports @version pinning, so it's fine.)

The curl | bash convenience is nice - it'd be great to also have the same pointing at a GitHub Releases asset directly, so users can verify what they're running against a tagged release.

Why this matters now

The project is growing fast - v0.12.0 had 10 of 14 PRs from external contributors, and recent releases regularly include first-time contributors (e.g. v0.16.7: "2 PRs, 1 from an external contributor, 1 first-timer"). More contributors means more attack surface:

• Single primary maintainer (@backnotprop) - one compromised account could push a malicious release (contributors graph)
• The project is ~3.5 months old (created 2025-12-28) with a very rapid release cadence
• Plannator runs as a Claude Code hook on PermissionRequest events - a compromised version sits in a privileged position
• The curl | bash fetches from plannotator.ai, not from a GitHub release with a verifiable tag/checksum
• The axios compromise (March 31, 2026) showed what happens when a single maintainer account gets popped - ~100M weekly downloads affected

Modern package managers now support dependency cooldowns (see Package Managers Need to Cool Down) - even a few days' delay catches the majority of supply chain attacks, hence why it would be nice to be able to manually achieve that with plannator plugin as well.

What would help

1. Version-pinned install from a trusted source - e.g. curl -fsSL https://plannotator.ai/install.sh | bash -s - -version v0.X.Y, ideally with a parallel option fetching from GitHub Releases directly
2. Immutable releases and artifact attestations - GitHub supports both immutable releases and artifact attestations, which let users verify a binary was built from a specific commit via a specific workflow and hasn't been tampered with. Relevant because supply chain attacks often inject payloads during CD, not in source (cf. litellm, xz)
3. Allow to either set a cooldown or complete disabling of update reminder in UI

[backnotprop]

All great feedback. Currently enabled: pinned actions, npm provenance, SHA256 verification, Renovate audit.

However, I've been wanting to move towards immutable and attestable builds with SLSA - we can even strive for L3 build isolation. I think producing SBOMS will be important. Yes, can commit to --version flag, immutable releases, build attestations, update cooldown setting.