2025-12-28 14:44:54 -08:00
|
|
|
@echo off
|
|
|
|
|
setlocal enabledelayedexpansion
|
|
|
|
|
|
|
|
|
|
REM Plannotator Windows CMD Bootstrap Script
|
|
|
|
|
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM Parse command line arguments
|
|
|
|
|
set "VERSION=latest"
|
|
|
|
|
REM Tracks whether a version was explicitly set via --version or positional.
|
|
|
|
|
REM Used to reject mixing --version <tag> with a stray positional token.
|
|
|
|
|
set "VERSION_EXPLICIT=0"
|
|
|
|
|
REM Three-layer opt-in for SLSA provenance verification.
|
|
|
|
|
REM Precedence: CLI flag > env var > %USERPROFILE%\.plannotator\config.json > default.
|
|
|
|
|
REM -1 = flag not set (fall through); 0 = disable; 1 = enable.
|
|
|
|
|
set "VERIFY_ATTESTATION_FLAG=-1"
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM Guided-install answers. Precedence: CLI flags > wizard (interactive, first
|
|
|
|
|
REM run or --reconfigure) > saved prefs from a previous run > defaults.
|
|
|
|
|
set "EXTRAS_FLAG="
|
|
|
|
|
set "MODEL_INVOCABLE_FLAG="
|
|
|
|
|
set "NON_INTERACTIVE=0"
|
|
|
|
|
set "RECONFIGURE=0"
|
feat(install): add --minimal binary-only install mode (#989)
* feat(install): add --minimal binary-only install mode
install.sh installs the plannotator binary and then writes a large amount
of extra state: the sem sidecar, the agent-terminal runtime, and per-agent
skills, hooks, slash commands, and config for Claude, Codex, OpenCode,
Gemini, and Kiro. There is no way to get just the binary — even the
--no-extras path still writes ~/.claude skills and OpenCode commands.
Add a --minimal flag (aliased --binary-only) plus a PLANNOTATOR_MINIMAL
env var for `curl | bash` runs. Minimal mode installs only the binary to
~/.local/bin, prints PATH advice, and exits before any sidecar download,
agent integration, skill checkout, config write, cache clear, or cleanup
migration. Precedence: flag > env var > default (off).
The PATH-advice block is extracted into print_path_advice() so both the
minimal early exit and the normal flow reuse it.
Closes #977
* feat(install): mirror minimal mode to ps1/cmd, add --no-minimal, docs
Extend the binary-only install mode to full cross-installer parity and
address the Copilot review on #989.
install.sh:
- Add --no-minimal (MINIMAL_FLAG=0) so a CLI flag can override
PLANNOTATOR_MINIMAL=1 in both directions; the -1/0/1 comment is now
accurate. --minimal/--no-minimal are mutually exclusive.
- Document the --binary-only alias and soften the absolute "nothing
written outside ..." wording to "no persistent state" (minimal mode
still uses a temp download file and may read the config dir).
install.ps1 / install.cmd:
- Add -Minimal (alias BinaryOnly)/-NoMinimal and --minimal/--binary-only/
--no-minimal with PLANNOTATOR_MINIMAL resolution, mirroring install.sh.
- Extract PATH advice into Show-PathAdvice / :PrintPathAdvice and reuse it
in both the minimal early exit and the normal flow.
- Early-exit after the binary is placed, before the sidecar/agent/skill/
config work.
Tests: add minimal-mode assertions to the install.ps1 and install.cmd
describe blocks plus a shared-behavior test asserting all three installers
support it; extend the sh tests for --no-minimal.
Docs: document --minimal / PLANNOTATOR_MINIMAL in the installation guide
(noting minimal mode needs no git) and add PLANNOTATOR_MINIMAL (and backfill
PLANNOTATOR_SKIP_SEM_INSTALL) to the env-var registries.
* docs(install): correct minimal-mode PATH wording (ps1 persists PATH)
The PowerShell installer's minimal path calls Show-PathAdvice, which
persistently writes the user PATH — so "no persistent state is written
outside $installDir" overpromised. Reword the install.ps1 comment and the
installation docs to describe what minimal mode skips (sidecar, agent
runtime, per-agent integrations) and note the binary + PATH entry are still
added on Windows. Addresses the second Copilot review on #989.
* fix(install.cmd): use delayed expansion for PLANNOTATOR_MINIMAL checks
The three new env-var checks used immediate %VAR% expansion; under
setlocal enabledelayedexpansion a poisoned value re-exposes cmd
metacharacters at parse time (command injection). Switch to the !VAR!
idiom the script already uses for every other untrusted env var (e.g.
the PLANNOTATOR_VERIFY_ATTESTATION block).
---------
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
2026-07-07 00:43:42 +02:00
|
|
|
REM Binary-only mode. Installs just plannotator.exe and no persistent state
|
|
|
|
|
REM elsewhere. Set by --minimal (1) / --no-minimal (0); -1 = neither flag given
|
|
|
|
|
REM (fall through to the PLANNOTATOR_MINIMAL env var, resolved after :args_done).
|
|
|
|
|
set "MINIMAL_FLAG=-1"
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM Per-agent integration opt-outs (#1178). Skip means do-not-write: a skipped
|
|
|
|
|
REM agent's home is neither written to nor cleaned up, and detected-but-skipped
|
|
|
|
|
REM is reported honestly. Resolution (flag > env var > config skipInstall.<agent>
|
|
|
|
|
REM > default off) happens after _CONFIG_DIR is known.
|
|
|
|
|
set "SKIP_CODEX_FLAG=0"
|
|
|
|
|
set "SKIP_GEMINI_FLAG=0"
|
|
|
|
|
set "SKIP_KIRO_FLAG=0"
|
|
|
|
|
set "SKIP_OPENCODE_FLAG=0"
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
REM Same shape, but scoped to the skills/slash-command sparse checkout rather
|
|
|
|
|
REM than one agent's home: --skip-skills turns the whole fetch into a no-op for
|
|
|
|
|
REM every scope it writes (Claude, .agents, OpenCode, Gemini, Kiro), including
|
|
|
|
|
REM the extras and the skill-scope cleanup sweeps.
|
|
|
|
|
set "SKIP_SKILLS_FLAG=0"
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
|
|
|
|
|
:parse_args
|
|
|
|
|
if "%~1"=="" goto args_done
|
|
|
|
|
if /i "%~1"=="--version" (
|
|
|
|
|
if "%~2"=="" (
|
|
|
|
|
echo --version requires an argument >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Reject dash-prefixed values - prevents `install.cmd --version
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM --skip-attestation` from silently setting VERSION=--skip-attestation.
|
|
|
|
|
set "NEXT_ARG=%~2"
|
|
|
|
|
if "!NEXT_ARG:~0,1!"=="-" (
|
|
|
|
|
echo --version requires a tag value, got flag: "%~2" >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
set "VERSION=%~2"
|
|
|
|
|
set "VERSION_EXPLICIT=1"
|
|
|
|
|
shift
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--verify-attestation" (
|
|
|
|
|
if "!VERIFY_ATTESTATION_FLAG!"=="0" (
|
|
|
|
|
echo --verify-attestation and --skip-attestation are mutually exclusive >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
set "VERIFY_ATTESTATION_FLAG=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--skip-attestation" (
|
|
|
|
|
if "!VERIFY_ATTESTATION_FLAG!"=="1" (
|
|
|
|
|
echo --skip-attestation and --verify-attestation are mutually exclusive >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
set "VERIFY_ATTESTATION_FLAG=0"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if /i "%~1"=="--extras" (
|
|
|
|
|
set "EXTRAS_FLAG=yes"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--no-extras" (
|
|
|
|
|
set "EXTRAS_FLAG=no"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--model-invocable" (
|
|
|
|
|
if "%~2"=="" (
|
|
|
|
|
echo --model-invocable requires a comma-separated skill list or 'none' >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
set "MODEL_INVOCABLE_FLAG=%~2"
|
|
|
|
|
shift
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--non-interactive" (
|
|
|
|
|
set "NON_INTERACTIVE=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--yes" (
|
|
|
|
|
set "NON_INTERACTIVE=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--reconfigure" (
|
|
|
|
|
set "RECONFIGURE=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
feat(install): add --minimal binary-only install mode (#989)
* feat(install): add --minimal binary-only install mode
install.sh installs the plannotator binary and then writes a large amount
of extra state: the sem sidecar, the agent-terminal runtime, and per-agent
skills, hooks, slash commands, and config for Claude, Codex, OpenCode,
Gemini, and Kiro. There is no way to get just the binary — even the
--no-extras path still writes ~/.claude skills and OpenCode commands.
Add a --minimal flag (aliased --binary-only) plus a PLANNOTATOR_MINIMAL
env var for `curl | bash` runs. Minimal mode installs only the binary to
~/.local/bin, prints PATH advice, and exits before any sidecar download,
agent integration, skill checkout, config write, cache clear, or cleanup
migration. Precedence: flag > env var > default (off).
The PATH-advice block is extracted into print_path_advice() so both the
minimal early exit and the normal flow reuse it.
Closes #977
* feat(install): mirror minimal mode to ps1/cmd, add --no-minimal, docs
Extend the binary-only install mode to full cross-installer parity and
address the Copilot review on #989.
install.sh:
- Add --no-minimal (MINIMAL_FLAG=0) so a CLI flag can override
PLANNOTATOR_MINIMAL=1 in both directions; the -1/0/1 comment is now
accurate. --minimal/--no-minimal are mutually exclusive.
- Document the --binary-only alias and soften the absolute "nothing
written outside ..." wording to "no persistent state" (minimal mode
still uses a temp download file and may read the config dir).
install.ps1 / install.cmd:
- Add -Minimal (alias BinaryOnly)/-NoMinimal and --minimal/--binary-only/
--no-minimal with PLANNOTATOR_MINIMAL resolution, mirroring install.sh.
- Extract PATH advice into Show-PathAdvice / :PrintPathAdvice and reuse it
in both the minimal early exit and the normal flow.
- Early-exit after the binary is placed, before the sidecar/agent/skill/
config work.
Tests: add minimal-mode assertions to the install.ps1 and install.cmd
describe blocks plus a shared-behavior test asserting all three installers
support it; extend the sh tests for --no-minimal.
Docs: document --minimal / PLANNOTATOR_MINIMAL in the installation guide
(noting minimal mode needs no git) and add PLANNOTATOR_MINIMAL (and backfill
PLANNOTATOR_SKIP_SEM_INSTALL) to the env-var registries.
* docs(install): correct minimal-mode PATH wording (ps1 persists PATH)
The PowerShell installer's minimal path calls Show-PathAdvice, which
persistently writes the user PATH — so "no persistent state is written
outside $installDir" overpromised. Reword the install.ps1 comment and the
installation docs to describe what minimal mode skips (sidecar, agent
runtime, per-agent integrations) and note the binary + PATH entry are still
added on Windows. Addresses the second Copilot review on #989.
* fix(install.cmd): use delayed expansion for PLANNOTATOR_MINIMAL checks
The three new env-var checks used immediate %VAR% expansion; under
setlocal enabledelayedexpansion a poisoned value re-exposes cmd
metacharacters at parse time (command injection). Switch to the !VAR!
idiom the script already uses for every other untrusted env var (e.g.
the PLANNOTATOR_VERIFY_ATTESTATION block).
---------
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
2026-07-07 00:43:42 +02:00
|
|
|
if /i "%~1"=="--minimal" (
|
|
|
|
|
if "!MINIMAL_FLAG!"=="0" (
|
|
|
|
|
echo --minimal and --no-minimal are mutually exclusive >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
set "MINIMAL_FLAG=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--binary-only" (
|
|
|
|
|
if "!MINIMAL_FLAG!"=="0" (
|
|
|
|
|
echo --binary-only and --no-minimal are mutually exclusive >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
set "MINIMAL_FLAG=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--no-minimal" (
|
|
|
|
|
if "!MINIMAL_FLAG!"=="1" (
|
|
|
|
|
echo --no-minimal and --minimal are mutually exclusive >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
set "MINIMAL_FLAG=0"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
if /i "%~1"=="--skip-codex" (
|
|
|
|
|
set "SKIP_CODEX_FLAG=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--skip-gemini" (
|
|
|
|
|
set "SKIP_GEMINI_FLAG=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--skip-kiro" (
|
|
|
|
|
set "SKIP_KIRO_FLAG=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
|
|
|
|
if /i "%~1"=="--skip-opencode" (
|
|
|
|
|
set "SKIP_OPENCODE_FLAG=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
if /i "%~1"=="--skip-skills" (
|
|
|
|
|
set "SKIP_SKILLS_FLAG=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
)
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM Reject any other dash-prefixed token as an unknown option, so a typoed
|
|
|
|
|
REM flag like --verify-attesttion fails fast instead of being interpreted as
|
|
|
|
|
REM a version tag (which would 404 on releases/download/v--verify-attesttion/...).
|
|
|
|
|
REM
|
|
|
|
|
REM Uses a variable-assigned substring test instead of `echo %~1 | findstr`
|
|
|
|
|
REM because unquoted %~1 in an echo pipe lets cmd.exe interpret shell
|
|
|
|
|
REM metacharacters (& | > <) in the argument before the pipe runs. Assigning
|
|
|
|
|
REM to a `set "VAR=%~1"` literal-quoted form preserves metacharacters safely,
|
|
|
|
|
REM and delayed-expansion substring (!VAR:~0,1!) avoids the subprocess entirely.
|
2026-07-10 06:50:40 -07:00
|
|
|
REM The error-message echo also quotes "%~1" for the same reason - echoing an
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM unquoted arg containing `&` would re-trigger metacharacter interpretation.
|
|
|
|
|
set "CURRENT_ARG=%~1"
|
|
|
|
|
if "!CURRENT_ARG:~0,1!"=="-" (
|
|
|
|
|
echo Unknown option: "%~1" >&2
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
echo Usage: install.cmd [--version ^<tag^>] [--verify-attestation ^| --skip-attestation] [--extras ^| --no-extras] [--model-invocable ^<list^>] [--minimal ^| --no-minimal] [--skip-codex] [--skip-gemini] [--skip-kiro] [--skip-opencode] [--skip-skills] [--non-interactive] [--reconfigure] >&2
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
REM Positional form: install.cmd vX.Y.Z (legacy interface).
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Reject if --version was already passed - silent overwrite is worse
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM than a clean usage error.
|
|
|
|
|
if "!VERSION_EXPLICIT!"=="1" (
|
|
|
|
|
echo Unexpected positional argument: "%~1" ^(version already set^) >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
2025-12-28 14:44:54 -08:00
|
|
|
set "VERSION=%~1"
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
set "VERSION_EXPLICIT=1"
|
|
|
|
|
shift
|
|
|
|
|
goto parse_args
|
|
|
|
|
:args_done
|
2025-12-28 14:44:54 -08:00
|
|
|
|
feat(install): add --minimal binary-only install mode (#989)
* feat(install): add --minimal binary-only install mode
install.sh installs the plannotator binary and then writes a large amount
of extra state: the sem sidecar, the agent-terminal runtime, and per-agent
skills, hooks, slash commands, and config for Claude, Codex, OpenCode,
Gemini, and Kiro. There is no way to get just the binary — even the
--no-extras path still writes ~/.claude skills and OpenCode commands.
Add a --minimal flag (aliased --binary-only) plus a PLANNOTATOR_MINIMAL
env var for `curl | bash` runs. Minimal mode installs only the binary to
~/.local/bin, prints PATH advice, and exits before any sidecar download,
agent integration, skill checkout, config write, cache clear, or cleanup
migration. Precedence: flag > env var > default (off).
The PATH-advice block is extracted into print_path_advice() so both the
minimal early exit and the normal flow reuse it.
Closes #977
* feat(install): mirror minimal mode to ps1/cmd, add --no-minimal, docs
Extend the binary-only install mode to full cross-installer parity and
address the Copilot review on #989.
install.sh:
- Add --no-minimal (MINIMAL_FLAG=0) so a CLI flag can override
PLANNOTATOR_MINIMAL=1 in both directions; the -1/0/1 comment is now
accurate. --minimal/--no-minimal are mutually exclusive.
- Document the --binary-only alias and soften the absolute "nothing
written outside ..." wording to "no persistent state" (minimal mode
still uses a temp download file and may read the config dir).
install.ps1 / install.cmd:
- Add -Minimal (alias BinaryOnly)/-NoMinimal and --minimal/--binary-only/
--no-minimal with PLANNOTATOR_MINIMAL resolution, mirroring install.sh.
- Extract PATH advice into Show-PathAdvice / :PrintPathAdvice and reuse it
in both the minimal early exit and the normal flow.
- Early-exit after the binary is placed, before the sidecar/agent/skill/
config work.
Tests: add minimal-mode assertions to the install.ps1 and install.cmd
describe blocks plus a shared-behavior test asserting all three installers
support it; extend the sh tests for --no-minimal.
Docs: document --minimal / PLANNOTATOR_MINIMAL in the installation guide
(noting minimal mode needs no git) and add PLANNOTATOR_MINIMAL (and backfill
PLANNOTATOR_SKIP_SEM_INSTALL) to the env-var registries.
* docs(install): correct minimal-mode PATH wording (ps1 persists PATH)
The PowerShell installer's minimal path calls Show-PathAdvice, which
persistently writes the user PATH — so "no persistent state is written
outside $installDir" overpromised. Reword the install.ps1 comment and the
installation docs to describe what minimal mode skips (sidecar, agent
runtime, per-agent integrations) and note the binary + PATH entry are still
added on Windows. Addresses the second Copilot review on #989.
* fix(install.cmd): use delayed expansion for PLANNOTATOR_MINIMAL checks
The three new env-var checks used immediate %VAR% expansion; under
setlocal enabledelayedexpansion a poisoned value re-exposes cmd
metacharacters at parse time (command injection). Switch to the !VAR!
idiom the script already uses for every other untrusted env var (e.g.
the PLANNOTATOR_VERIFY_ATTESTATION block).
---------
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
2026-07-07 00:43:42 +02:00
|
|
|
REM Resolve binary-only mode. Precedence: --minimal / --no-minimal flag >
|
|
|
|
|
REM PLANNOTATOR_MINIMAL env var > default (off). Mirrors install.sh / install.ps1.
|
|
|
|
|
set "MINIMAL=0"
|
|
|
|
|
if /i "!PLANNOTATOR_MINIMAL!"=="1" set "MINIMAL=1"
|
|
|
|
|
if /i "!PLANNOTATOR_MINIMAL!"=="true" set "MINIMAL=1"
|
|
|
|
|
if /i "!PLANNOTATOR_MINIMAL!"=="yes" set "MINIMAL=1"
|
|
|
|
|
if "!MINIMAL_FLAG!"=="1" set "MINIMAL=1"
|
|
|
|
|
if "!MINIMAL_FLAG!"=="0" set "MINIMAL=0"
|
|
|
|
|
|
2025-12-28 14:44:54 -08:00
|
|
|
set "REPO=backnotprop/plannotator"
|
feat(review): add semantic diff overview (#871)
* feat(review): add semantic diff overview
* fix(review): address semantic diff review findings
* fix(review): harden semantic diff fallback
* fix(review): avoid repo-local sem execution
* fix(review): normalize semantic diff cwd
* test(review): cover semantic diff local cwd
* fix(gitlab): fetch raw MR diffs
* fix(review): harden sem path resolution
* docs(review): add semantic diff handoff
* feat(review): semantic diff cards, header sem badges, jump-to-line
- Restyle the semantic panel as real bordered cards (shadcn surface) instead
of ASCII box-drawing; centered column, grid-aligned entity rows.
- Hide orphan (module-level) changes from the rows, matching sem's default;
the count still surfaces in the summary line.
- Add a 'sem · N' hover popover to each diff file header showing that file's
semantic changes, reusing the same row component as the panel.
- Clicking an entity (panel or popover) scrolls the diff to the lines via
pierre's [data-selected-line]; centers only when off-screen so manual
drag-selection isn't disturbed.
- Extract shared rows/helpers into semanticDiffShared; share one cached
/api/semantic-diff fetch across header badges.
* feat(review): land on All files by default
Semantic diff stays available via the file-tree nav entry and header badges,
but it's no longer the initial landing view.
* chore(review): drop dead change-symbol entries, log badge fetch failures
- Remove unreachable 'moved'/'renamed' entries from the changeSymbols table
(getChangeSymbol early-returns for those before the lookup).
- Log a console.error once per patch when the file-header badge's semantic
diff fetch fails or returns a non-ok status, so a systemic failure leaves a
trace instead of every badge silently showing nothing.
* feat(review): flatten semantic diff panel into grouped list
- Dissolve the per-file bordered cards into flat sections: the file path is now
a quiet underlined header (single hairline) with entity rows flush beneath,
hierarchy from whitespace + hover tint instead of boxes.
- Split the path into muted directory + emphasized filename for faster scanning.
- Nudge the add/remove glyphs (⊕/⊖) ~15% larger, line-height pinned so rows
don't grow; modified/rename/reorder glyphs unchanged.
2026-06-08 22:23:54 -07:00
|
|
|
set "SEM_REPO=Ataraxy-Labs/sem"
|
|
|
|
|
set "SEM_VERSION=v0.8.0"
|
2025-12-28 14:44:54 -08:00
|
|
|
set "INSTALL_DIR=%USERPROFILE%\.local\bin"
|
|
|
|
|
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM First plannotator release that carries SLSA build-provenance attestations.
|
2026-07-10 06:50:40 -07:00
|
|
|
REM See scripts/install.sh for the full explanation - this constant is
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM bumped once at the first attested release via the release skill.
|
|
|
|
|
set "MIN_ATTESTED_VERSION=v0.17.2"
|
|
|
|
|
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM Attestation-bundle fetch helper, passed to PowerShell via -EncodedCommand
|
|
|
|
|
REM so NO script file ever touches %%TEMP%% (a %%RANDOM%%-named .ps1 would be a
|
|
|
|
|
REM predictable-path code-execution vector). Inputs travel via env vars
|
|
|
|
|
REM (REPO, ATT_DIGEST, ATT_BUNDLE_FILE); exit codes: 0 = bundle written,
|
|
|
|
|
REM 2 = fetch failed, 3 = nothing extracted. The blob decodes to EXACTLY the
|
|
|
|
|
REM script below (UTF-16LE base64). scripts/install.test.ts decodes the blob,
|
|
|
|
|
REM asserts it matches these REM PS: lines byte for byte, and executes its
|
|
|
|
|
REM scanner against a captured real attestations response - so the blob
|
|
|
|
|
REM cannot silently drift from what is documented here. Regenerate after
|
|
|
|
|
REM editing the REM PS: lines:
|
|
|
|
|
REM [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($script))
|
|
|
|
|
REM PS: $ErrorActionPreference = 'Stop'
|
|
|
|
|
REM PS: try {
|
|
|
|
|
REM PS: $resp = Invoke-WebRequest -Uri ('https://api.github.com/repos/' + $env:REPO + '/attestations/sha256:' + $env:ATT_DIGEST) -UseBasicParsing -TimeoutSec 30
|
|
|
|
|
REM PS: $raw = if ($resp.Content -is [byte[]]) { [System.Text.Encoding]::UTF8.GetString($resp.Content) } else { [string]$resp.Content }
|
|
|
|
|
REM PS: } catch { exit 2 }
|
|
|
|
|
REM PS: $bundles = @()
|
|
|
|
|
REM PS: $searchFrom = 0
|
|
|
|
|
REM PS: while ($true) {
|
|
|
|
|
REM PS: $keyIdx = $raw.IndexOf('"bundle"', $searchFrom, [System.StringComparison]::Ordinal)
|
|
|
|
|
REM PS: if ($keyIdx -lt 0) { break }
|
|
|
|
|
REM PS: $searchFrom = $keyIdx + 8
|
|
|
|
|
REM PS: $i = $keyIdx + 8
|
|
|
|
|
REM PS: while ($i -lt $raw.Length -and [char]::IsWhiteSpace($raw[$i])) { $i++ }
|
|
|
|
|
REM PS: if ($i -ge $raw.Length -or $raw[$i] -ne ':') { continue }
|
|
|
|
|
REM PS: $i++
|
|
|
|
|
REM PS: while ($i -lt $raw.Length -and [char]::IsWhiteSpace($raw[$i])) { $i++ }
|
|
|
|
|
REM PS: if ($i -ge $raw.Length -or $raw[$i] -ne '{') { continue }
|
|
|
|
|
REM PS: $depth = 0
|
|
|
|
|
REM PS: $inString = $false
|
|
|
|
|
REM PS: $escaped = $false
|
|
|
|
|
REM PS: $start = $i
|
|
|
|
|
REM PS: for (; $i -lt $raw.Length; $i++) {
|
|
|
|
|
REM PS: $ch = $raw[$i]
|
|
|
|
|
REM PS: if ($escaped) { $escaped = $false; continue }
|
|
|
|
|
REM PS: if ($inString) {
|
|
|
|
|
REM PS: if ($ch -eq '\') { $escaped = $true }
|
|
|
|
|
REM PS: elseif ($ch -eq '"') { $inString = $false }
|
|
|
|
|
REM PS: continue
|
|
|
|
|
REM PS: }
|
|
|
|
|
REM PS: if ($ch -eq '"') { $inString = $true; continue }
|
|
|
|
|
REM PS: if ($ch -eq '{') { $depth++; continue }
|
|
|
|
|
REM PS: if ($ch -eq '}') {
|
|
|
|
|
REM PS: $depth--
|
|
|
|
|
REM PS: if ($depth -eq 0) {
|
|
|
|
|
REM PS: $bundles += $raw.Substring($start, $i - $start + 1)
|
|
|
|
|
REM PS: $searchFrom = $i + 1
|
|
|
|
|
REM PS: break
|
|
|
|
|
REM PS: }
|
|
|
|
|
REM PS: }
|
|
|
|
|
REM PS: }
|
|
|
|
|
REM PS: }
|
|
|
|
|
REM PS: if ($bundles.Count -eq 0) { exit 3 }
|
|
|
|
|
REM PS: try { [System.IO.File]::WriteAllText($env:ATT_BUNDLE_FILE, (($bundles -join [char]10) + [char]10)) } catch { exit 3 }
|
|
|
|
|
REM PS: exit 0
|
|
|
|
|
set "ATT_FETCH_B64=JABFAHIAcgBvAHIAQQBjAHQAaQBvAG4AUAByAGUAZgBlAHIAZQBuAGMAZQAgAD0AIAAnAFMAdABvAHAAJwAKAHQAcgB5ACAAewAKACAAIAAgACAAJAByAGUAcwBwACAAPQAgAEkAbgB2AG8AawBlAC0AVwBlAGIAUgBlAHEAdQBlAHMAdAAgAC0AVQByAGkAIAAoACcAaAB0AHQAcABzADoALwAvAGEAcABpAC4AZwBpAHQAaAB1AGIALgBjAG8AbQAvAHIAZQBwAG8AcwAvACcAIAArACAAJABlAG4AdgA6AFIARQBQAE8AIAArACAAJwAvAGEAdAB0AGUAcwB0AGEAdABpAG8AbgBzAC8AcwBoAGEAMgA1ADYAOgAnACAAKwAgACQAZQBuAHYAOgBBAFQAVABfAEQASQBHAEUAUwBUACkAIAAtAFUAcwBlAEIAYQBzAGkAYwBQAGEAcgBzAGkAbgBnACAALQBUAGkAbQBlAG8AdQB0AFMAZQBjACAAMwAwAAoAIAAgACAAIAAkAHIAYQB3ACAAPQAgAGkAZgAgACgAJAByAGUAcwBwAC4AQwBvAG4AdABlAG4AdAAgAC0AaQBzACAAWwBiAHkAdABlAFsAXQBdACkAIAB7ACAAWwBTAHkAcwB0AGUAbQAuAFQAZQB4AHQALgBFAG4AYwBvAGQAaQBuAGcAXQA6ADoAVQBUAEYAOAAuAEcAZQB0AFMAdAByAGkAbgBnACgAJAByAGUAcwBwAC4AQwBvAG4AdABlAG4AdAApACAAfQAgAGUAbABzAGUAIAB7ACAAWwBzAHQAcgBpAG4AZwBdACQAcgBlAHMAcAAuAEMAbwBuAHQAZQBuAHQAIAB9AAoAfQAgAGMAYQB0AGMAaAAgAHsAIABlAHgAaQB0ACAAMgAgAH0ACgAkAGIAdQBuAGQAbABlAHMAIAA9ACAAQAAoACkACgAkAHMAZQBhAHIAYwBoAEYAcgBvAG0AIAA9ACAAMAAKAHcAaABpAGwAZQAgACgAJAB0AHIAdQBlACkAIAB7AAoAIAAgACAAIAAkAGsAZQB5AEkAZAB4ACAAPQAgACQAcgBhAHcALgBJAG4AZABlAHgATwBmACgAJwAiAGIAdQBuAGQAbABlACIAJwAsACAAJABzAGUAYQByAGMAaABGAHIAbwBtACwAIABbAFMAeQBzAHQAZQBtAC4AUwB0AHIAaQBuAGcAQwBvAG0AcABhAHIAaQBzAG8AbgBdADoAOgBPAHIAZABpAG4AYQBsACkACgAgACAAIAAgAGkAZgAgACgAJABrAGUAeQBJAGQAeAAgAC0AbAB0ACAAMAApACAAewAgAGIAcgBlAGEAawAgAH0ACgAgACAAIAAgACQAcwBlAGEAcgBjAGgARgByAG8AbQAgAD0AIAAkAGsAZQB5AEkAZAB4ACAAKwAgADgACgAgACAAIAAgACQAaQAgAD0AIAAkAGsAZQB5AEkAZAB4ACAAKwAgADgACgAgACAAIAAgAHcAaABpAGwAZQAgACgAJABpACAALQBsAHQAIAAkAHIAYQB3AC4ATABlAG4AZwB0AGgAIAAtAGEAbgBkACAAWwBjAGgAYQByAF0AOgA6AEkAcwBXAGgAaQB0AGUAUwBwAGEAYwBlACgAJAByAGEAdwBbACQAaQBdACkAKQAgAHsAIAAkAGkAKwArACAAfQAKACAAIAAgACAAaQBmACAAKAAkAGkAIAAtAGcAZQAgACQAcgBhAHcALgBMAGUAbgBnAHQAaAAgAC0AbwByACAAJAByAGEAdwBbACQAaQBdACAALQBuAGUAIAAnADoAJwApACAAewAgAGMAbwBuAHQAaQBuAHUAZQAgAH0ACgAgACAAIAAgACQAaQArACsACgAgACAAIAAgAHcAaABpAGwAZQAgACgAJABpACAALQBsAHQAIAAkAHIAYQB3AC4ATABlAG4AZwB0AGgAIAAtAGEAbgBkACAAWwBjAGgAYQByAF0AOgA6AEkAcwBXAGgAaQB0AGUAUwBwAGEAYwBlACgAJAByAGEAdwBbACQAaQBdACkAKQAgAHsAIAAkAGkAKwArACAAfQAKACAAIAAgACAAaQBmACAAKAAkAGkAIAAtAGcAZQAgACQAcgBhAHcALgBMAGUAbgBnAHQAaAAgAC0AbwByACAAJAByAGEAdwBbACQAaQBdACAALQBuAGUAIAAnAHsAJwApACAAewAgAGMAbwBuAHQAaQBuAHUAZQAgAH0ACgAgACAAIAAgACQAZABlAHAAdABoACAAPQAgADAACgAgACAAIAAgACQAaQBuAFMAdAByAGkAbgBnACAAPQAgACQAZgBhAGwAcwBlAAoAIAAgACAAIAAkAGUAcwBjAGEAcABlAGQAIAA9ACAAJABmAGEAbABzAGUACgAgACAAIAAgACQAcwB0AGEAcgB0ACAAPQAgACQAaQAKACAAIAAgACAAZgBvAHIAIAAoADsAIAAkAGkAIAAtAGwAdAAgACQAcgBhAHcALgBMAGUAbgBnAHQAaAA7ACAAJABpACsAKwApACAAewAKACAAIAAgACAAIAAgACAAIAAkAGMAaAAgAD0AIAAkAHIAYQB3AFsAJABpAF0ACgAgACAAIAAgACAAIAAgACAAaQBmACAAKAAkAGUAcwBjAGEAcABlAGQAKQAgAHsAIAAkAGUAcwBjAGEAcABlAGQAIAA9ACAAJABmAGEAbABzAGUAOwAgAGMAbwBuAHQAaQBuAHUAZQAgAH0ACgAgACAAIAAgACAAIAAgACAAaQBmACAAKAAkAGkAbgBTAHQAcgBpAG4AZwApACAAewAKACAAIAAgACAAIAAgACAAIAAgACAAIAAgAGkAZgAgACgAJABjAGgAIAAtAGUAcQAgACcAXAAnACkAIAB7ACAAJABlAHMAYwBhAHAAZQBkACAAPQAgACQAdAByAHUAZQAgAH0ACgAgACAAIAAgACAAIAAgACAAIAAgACAAIABlAGwAcwBlAGkAZgAgACgAJABjAGgAIAAtAGUAcQAgACcAIgAnACkAIAB7ACAAJABpAG4AUwB0AHIAaQBuAGcAIAA9ACAAJABmAGEAbABzAGUAIAB9AAoAIAAgACAAIAAgACAAIAAgACAAIAAgACAAYwBvAG4AdABpAG4AdQBlAAoAIAAgACAAIAAgACAAIAAgAH0ACgAgACAAIAAgACAAIAAgACAAaQBmACAAKAAkAGMAaAAgAC0AZQBxACAAJwAiACcAKQAgAHsAIAAkAGkAbgBTAHQAcgBpAG4AZwAgAD0AIAAkAHQAcgB1AGUAOwAgAGMAbwBuAHQAaQBuAHUAZQAgAH0ACgAgACAAIAAgACAAIAAgACAAaQBmACAAKAAkAGMAaAAgAC0AZQBxACAAJwB7ACcAKQAgAHsAIAAkAGQAZQBwAHQAaAArACsAOwAgAGMAbwBuAHQAaQBuAHUAZQAgAH0ACgAgACAAIAAgACAAIAAgACAAaQBmACAAKAAkAGMAaAAgAC0AZQBxACAAJwB9ACcAKQAgAHsACgAgACAAIAAgACAAIAAgACAAIAAgACAAIAAkAGQAZQBwAHQAaAAtAC0ACgAgACAAIAAgACAAIAAgACAAIAAgACAAIABpAGYAIAAoACQAZABlAHAAdABoACAALQBlAHEAIAAwACkAIAB7AAoAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAkAGIAdQBuAGQAbABlAHMAIAArAD0AIAAkAHIAYQB3AC4AUwB1AGIAcwB0AHIAaQBuAGcAKAAkAHMAdABhAHIAdAAsACAAJABpACAALQAgACQAcwB0AGEAcgB0ACAAKwAgADEAKQAKACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAJABzAGUAYQByAGMAaABGAHIAbwBtACAAPQAgACQAaQAgACsAIAAxAAoAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABiAHIAZQBhAGsACgAgACAAIAAgACAAIAAgACAAIAAgACAAIAB9
|
|
|
|
|
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM Detect architecture. Native ARM64 Windows binaries are built from
|
|
|
|
|
REM bun-windows-arm64 (stable since Bun v1.3.10), so ARM64 hosts get a
|
2026-07-10 06:50:40 -07:00
|
|
|
REM native binary - no Windows x86-64 emulation tax. PROCESSOR_ARCHITECTURE
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM reports the architecture the current cmd.exe process is running under;
|
|
|
|
|
REM PROCESSOR_ARCHITEW6432 is set only in 32-bit processes running via
|
|
|
|
|
REM WoW64 and reflects the host architecture (covers the edge case of a
|
|
|
|
|
REM 32-bit tool launching install.cmd on an ARM64 machine).
|
|
|
|
|
set "PLATFORM="
|
|
|
|
|
if /i "%PROCESSOR_ARCHITECTURE%"=="AMD64" set "PLATFORM=win32-x64"
|
|
|
|
|
if /i "%PROCESSOR_ARCHITECTURE%"=="ARM64" set "PLATFORM=win32-arm64"
|
|
|
|
|
if /i "%PROCESSOR_ARCHITEW6432%"=="AMD64" set "PLATFORM=win32-x64"
|
|
|
|
|
if /i "%PROCESSOR_ARCHITEW6432%"=="ARM64" set "PLATFORM=win32-arm64"
|
|
|
|
|
|
|
|
|
|
if "!PLATFORM!"=="" (
|
|
|
|
|
echo Plannotator does not support 32-bit Windows. >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
2025-12-28 14:44:54 -08:00
|
|
|
|
|
|
|
|
REM Check for curl availability
|
|
|
|
|
curl --version >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
echo curl is required but not available. Please use the PowerShell installer. >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
REM Create install directory
|
|
|
|
|
if not exist "!INSTALL_DIR!" mkdir "!INSTALL_DIR!"
|
|
|
|
|
|
|
|
|
|
REM Get version to install
|
|
|
|
|
if /i "!VERSION!"=="latest" (
|
|
|
|
|
echo Fetching latest version...
|
|
|
|
|
|
fix(install): authenticate api.github.com call to avoid 60/hr rate limit (#1157)
* fix(install): authenticate api.github.com call to avoid 60/hr rate limit
All three installers called api.github.com/repos/.../releases/latest
unauthenticated to resolve the latest release tag. GitHub caps
unauthenticated REST API requests at 60/hour per source IP (shared
across NAT/CGNAT/corporate proxy users), causing opaque 'Failed to
fetch latest version' errors.
Each installer now detects a token (precedence: GITHUB_TOKEN env >
GH_TOKEN env > 'gh auth token') and attaches it as an Authorization:
Bearer header to ONLY the version-resolution API call. Falls back to
anonymous (unchanged behavior) when no token is available. Release
downloads and git clone are left unauthenticated - they are not subject
to the 60/hr REST limit.
Token variables are cleared from memory immediately after the API call
(defense in depth). install.ps1 wraps the API call in try/catch to
surface a friendlier error instead of a raw terminating exception under
$ErrorActionPreference=Stop.
Docs updated with a rate-limited-IP install section and a troubleshooting
entry. Parity + negative-assertion tests added.
Closes #1156
* fix(install): retry anonymously when authenticated api call fails
Addresses review feedback on #1157: a stale/revoked token (expired
GITHUB_TOKEN lingering in CI images, dotfiles, direnv) gets a 401 and
would break an install that works fine anonymously today.
Each installer now retries the api.github.com version-resolution call
without the auth header when the authenticated attempt fails:
- install.sh: `|| true` + `[ -z "$latest_tag" ]` gate
- install.ps1: try/catch, retries with no -Headers on catch
- install.cmd: ERRORLEVEL check, retries without !GH_AUTH_HEADER!
A bad token costs one extra request; nobody is worse off than today.
New test asserts the retry path exists in all three installers (89 pass).
Also corrects the AI disclosure: the assistant was opencode, not Claude.
* fix(install): address second-review findings
Errorlevel check adjacency in install.cmd, delayed-expansion token
reads, token charset guard, PATH-resolved gh with --hostname
github.com, 401-only anonymous retry in install.sh and install.ps1,
preserved original errors in install.ps1, honest cleanup comments,
non-vacuous test assertions, and doc corrections (1000/hr Actions
token, zero-scope guidance, -Version for PowerShell).
---------
Co-authored-by: tbontb-iaq <tbontb-iaq@users.noreply.github.com>
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
2026-07-31 11:18:14 +08:00
|
|
|
REM api.github.com caps unauthenticated requests at 60/hour per source IP,
|
|
|
|
|
REM which fails installs behind shared egress IPs (NAT/CGNAT/corporate
|
|
|
|
|
REM proxies) and during repeated/debug runs within an hour. Attach an
|
|
|
|
|
REM Authorization header when a token is available (raises the limit to
|
|
|
|
|
REM 5000/hour); when none is found, fall back to anonymous (unchanged
|
|
|
|
|
REM behavior). Precedence matches `gh`: GITHUB_TOKEN > GH_TOKEN > gh auth token.
|
|
|
|
|
REM Read the env vars via delayed expansion, never percent expansion, so
|
|
|
|
|
REM the value is not re-parsed by cmd's phase-1 expansion - a value
|
|
|
|
|
REM containing metacharacters or exclamation marks can neither inject
|
|
|
|
|
REM commands nor be corrupted here.
|
|
|
|
|
set "GH_TOKEN_VAL="
|
|
|
|
|
if defined GITHUB_TOKEN set "GH_TOKEN_VAL=!GITHUB_TOKEN!"
|
|
|
|
|
if not defined GH_TOKEN_VAL if defined GH_TOKEN set "GH_TOKEN_VAL=!GH_TOKEN!"
|
|
|
|
|
if not defined GH_TOKEN_VAL (
|
|
|
|
|
REM Resolve gh via `where` and invoke the absolute path so the for /f
|
|
|
|
|
REM command line never runs a bare `gh` name, which cmd would resolve
|
|
|
|
|
REM from the current directory first. (`where` itself also searches
|
|
|
|
|
REM the CWD first - accepted limitation, documented here.)
|
|
|
|
|
REM --hostname github.com scopes the fallback to github.com
|
|
|
|
|
REM credentials, so a gh setup whose default host is a GitHub
|
|
|
|
|
REM Enterprise server never leaks a GHES token to api.github.com. On
|
|
|
|
|
REM an ancient gh without the flag, stderr is swallowed and we fall
|
|
|
|
|
REM back to anonymous.
|
|
|
|
|
set "GH_EXE="
|
|
|
|
|
for /f "delims=" %%g in ('where gh 2^>nul') do if not defined GH_EXE set "GH_EXE=%%g"
|
|
|
|
|
if defined GH_EXE (
|
|
|
|
|
for /f "delims=" %%i in ('"!GH_EXE!" auth token --hostname github.com 2^>nul') do set "GH_TOKEN_VAL=%%i"
|
|
|
|
|
)
|
|
|
|
|
set "GH_EXE="
|
|
|
|
|
)
|
|
|
|
|
REM Charset allowlist: GitHub tokens are [A-Za-z0-9_] (plus - to be
|
|
|
|
|
REM safe). Strip every allowed character (cmd substitution is
|
|
|
|
|
REM case-insensitive, covering A-Z too); anything left over means an
|
|
|
|
|
REM unexpected character - a quote in particular could break out of the
|
|
|
|
|
REM quoted Authorization header on the curl line below - so drop the
|
|
|
|
|
REM token and go anonymous. Done with pure delayed-expansion
|
|
|
|
|
REM substitutions: a findstr pipe cannot be used because delayed
|
|
|
|
|
REM expansion does not survive into pipe children, and writing the token
|
|
|
|
|
REM to a temp file for findstr would leak the secret to disk.
|
|
|
|
|
if defined GH_TOKEN_VAL (
|
|
|
|
|
set "TOKEN_RESIDUE=!GH_TOKEN_VAL!"
|
|
|
|
|
for %%c in (a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 _ -) do if defined TOKEN_RESIDUE set "TOKEN_RESIDUE=!TOKEN_RESIDUE:%%c=!"
|
|
|
|
|
if defined TOKEN_RESIDUE set "GH_TOKEN_VAL="
|
|
|
|
|
set "TOKEN_RESIDUE="
|
|
|
|
|
)
|
|
|
|
|
if defined GH_TOKEN_VAL (
|
|
|
|
|
set "GH_AUTH_HEADER=-H "Authorization: Bearer !GH_TOKEN_VAL!""
|
|
|
|
|
) else (
|
|
|
|
|
set "GH_AUTH_HEADER="
|
|
|
|
|
)
|
|
|
|
|
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM Download release info to a randomized temp file so concurrent
|
|
|
|
|
REM invocations don't collide and a same-user pre-placed symlink at
|
|
|
|
|
REM a predictable path can't redirect curl's output.
|
|
|
|
|
set "RELEASE_JSON=%TEMP%\plannotator-release-%RANDOM%.json"
|
fix(install): authenticate api.github.com call to avoid 60/hr rate limit (#1157)
* fix(install): authenticate api.github.com call to avoid 60/hr rate limit
All three installers called api.github.com/repos/.../releases/latest
unauthenticated to resolve the latest release tag. GitHub caps
unauthenticated REST API requests at 60/hour per source IP (shared
across NAT/CGNAT/corporate proxy users), causing opaque 'Failed to
fetch latest version' errors.
Each installer now detects a token (precedence: GITHUB_TOKEN env >
GH_TOKEN env > 'gh auth token') and attaches it as an Authorization:
Bearer header to ONLY the version-resolution API call. Falls back to
anonymous (unchanged behavior) when no token is available. Release
downloads and git clone are left unauthenticated - they are not subject
to the 60/hr REST limit.
Token variables are cleared from memory immediately after the API call
(defense in depth). install.ps1 wraps the API call in try/catch to
surface a friendlier error instead of a raw terminating exception under
$ErrorActionPreference=Stop.
Docs updated with a rate-limited-IP install section and a troubleshooting
entry. Parity + negative-assertion tests added.
Closes #1156
* fix(install): retry anonymously when authenticated api call fails
Addresses review feedback on #1157: a stale/revoked token (expired
GITHUB_TOKEN lingering in CI images, dotfiles, direnv) gets a 401 and
would break an install that works fine anonymously today.
Each installer now retries the api.github.com version-resolution call
without the auth header when the authenticated attempt fails:
- install.sh: `|| true` + `[ -z "$latest_tag" ]` gate
- install.ps1: try/catch, retries with no -Headers on catch
- install.cmd: ERRORLEVEL check, retries without !GH_AUTH_HEADER!
A bad token costs one extra request; nobody is worse off than today.
New test asserts the retry path exists in all three installers (89 pass).
Also corrects the AI disclosure: the assistant was opencode, not Claude.
* fix(install): address second-review findings
Errorlevel check adjacency in install.cmd, delayed-expansion token
reads, token charset guard, PATH-resolved gh with --hostname
github.com, 401-only anonymous retry in install.sh and install.ps1,
preserved original errors in install.ps1, honest cleanup comments,
non-vacuous test assertions, and doc corrections (1000/hr Actions
token, zero-scope guidance, -Version for PowerShell).
---------
Co-authored-by: tbontb-iaq <tbontb-iaq@users.noreply.github.com>
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
2026-07-31 11:18:14 +08:00
|
|
|
curl -fsSL !GH_AUTH_HEADER! "https://api.github.com/repos/!REPO!/releases/latest" -o "!RELEASE_JSON!"
|
|
|
|
|
REM A stale/revoked token (expired GITHUB_TOKEN lingering in CI images,
|
|
|
|
|
REM dotfiles, direnv) gets a 401 here and would break an install that
|
|
|
|
|
REM works fine anonymously today. If the authenticated call failed and
|
|
|
|
|
REM we had a token, retry once without the header so a bad token costs
|
|
|
|
|
REM one extra request but never blocks an otherwise-working install.
|
|
|
|
|
REM Note: install.sh / install.ps1 inspect the HTTP status and retry
|
|
|
|
|
REM only on 401; capturing the status portably in batch is not worth the
|
|
|
|
|
REM complexity, so cmd retries on any failure when a token was used - an
|
|
|
|
|
REM accepted cmd-only compromise. See backnotprop/plannotator#1157.
|
|
|
|
|
REM Both ERRORLEVEL reads below sit immediately adjacent to the curl
|
|
|
|
|
REM they test (only REM lines and a no-op if in between); the token
|
|
|
|
|
REM clears deliberately come AFTER the failure check because `set` can
|
|
|
|
|
REM disturb ERRORLEVEL.
|
|
|
|
|
if !ERRORLEVEL! neq 0 if defined GH_AUTH_HEADER (
|
|
|
|
|
curl -fsSL "https://api.github.com/repos/!REPO!/releases/latest" -o "!RELEASE_JSON!"
|
|
|
|
|
)
|
2025-12-28 14:44:54 -08:00
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
echo Failed to get latest version >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
fix(install): authenticate api.github.com call to avoid 60/hr rate limit (#1157)
* fix(install): authenticate api.github.com call to avoid 60/hr rate limit
All three installers called api.github.com/repos/.../releases/latest
unauthenticated to resolve the latest release tag. GitHub caps
unauthenticated REST API requests at 60/hour per source IP (shared
across NAT/CGNAT/corporate proxy users), causing opaque 'Failed to
fetch latest version' errors.
Each installer now detects a token (precedence: GITHUB_TOKEN env >
GH_TOKEN env > 'gh auth token') and attaches it as an Authorization:
Bearer header to ONLY the version-resolution API call. Falls back to
anonymous (unchanged behavior) when no token is available. Release
downloads and git clone are left unauthenticated - they are not subject
to the 60/hr REST limit.
Token variables are cleared from memory immediately after the API call
(defense in depth). install.ps1 wraps the API call in try/catch to
surface a friendlier error instead of a raw terminating exception under
$ErrorActionPreference=Stop.
Docs updated with a rate-limited-IP install section and a troubleshooting
entry. Parity + negative-assertion tests added.
Closes #1156
* fix(install): retry anonymously when authenticated api call fails
Addresses review feedback on #1157: a stale/revoked token (expired
GITHUB_TOKEN lingering in CI images, dotfiles, direnv) gets a 401 and
would break an install that works fine anonymously today.
Each installer now retries the api.github.com version-resolution call
without the auth header when the authenticated attempt fails:
- install.sh: `|| true` + `[ -z "$latest_tag" ]` gate
- install.ps1: try/catch, retries with no -Headers on catch
- install.cmd: ERRORLEVEL check, retries without !GH_AUTH_HEADER!
A bad token costs one extra request; nobody is worse off than today.
New test asserts the retry path exists in all three installers (89 pass).
Also corrects the AI disclosure: the assistant was opencode, not Claude.
* fix(install): address second-review findings
Errorlevel check adjacency in install.cmd, delayed-expansion token
reads, token charset guard, PATH-resolved gh with --hostname
github.com, 401-only anonymous retry in install.sh and install.ps1,
preserved original errors in install.ps1, honest cleanup comments,
non-vacuous test assertions, and doc corrections (1000/hr Actions
token, zero-scope guidance, -Version for PowerShell).
---------
Co-authored-by: tbontb-iaq <tbontb-iaq@users.noreply.github.com>
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
2026-07-31 11:18:14 +08:00
|
|
|
REM Drop the local token copies; downloads and git clone are anonymous.
|
|
|
|
|
REM GITHUB_TOKEN / GH_TOKEN themselves remain in the environment exactly
|
|
|
|
|
REM as the user set them.
|
|
|
|
|
set "GH_TOKEN_VAL="
|
|
|
|
|
set "GH_AUTH_HEADER="
|
2025-12-28 14:44:54 -08:00
|
|
|
|
|
|
|
|
REM Extract tag_name from JSON
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
for /f "tokens=2 delims=:," %%i in ('findstr /c:"\"tag_name\"" "!RELEASE_JSON!"') do (
|
2025-12-28 14:44:54 -08:00
|
|
|
set "TAG=%%i"
|
|
|
|
|
set "TAG=!TAG: =!"
|
|
|
|
|
set "TAG=!TAG:"=!"
|
|
|
|
|
)
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
del "!RELEASE_JSON!"
|
2025-12-28 14:44:54 -08:00
|
|
|
|
|
|
|
|
if "!TAG!"=="" (
|
|
|
|
|
echo Failed to parse version >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
) else (
|
|
|
|
|
set "TAG=!VERSION!"
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM Add v prefix if not present. Use a substring test rather than
|
2026-07-10 06:50:40 -07:00
|
|
|
REM piping the expanded variable through findstr - an unquoted echo
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM pipe re-exposes cmd metacharacters (& | > <) in the value before
|
|
|
|
|
REM the pipe runs. Matches the safe pattern used in the arg parser.
|
|
|
|
|
if not "!TAG:~0,1!"=="v" set "TAG=v!TAG!"
|
2025-12-28 14:44:54 -08:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
echo Installing plannotator !TAG!...
|
|
|
|
|
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM Resolve SLSA build-provenance verification opt-in BEFORE the download so
|
|
|
|
|
REM we can fail fast without wasting bandwidth if the requested tag predates
|
|
|
|
|
REM provenance support. Precedence: CLI flag > env var > config.json > default.
|
|
|
|
|
set "VERIFY_ATTESTATION=0"
|
|
|
|
|
|
|
|
|
|
REM Layer 3: config file (lowest precedence of the opt-in sources).
|
2026-07-20 08:55:12 -07:00
|
|
|
REM Unset PLANNOTATOR_DATA_DIR: an existing %USERPROFILE%\.plannotator
|
|
|
|
|
REM (legacy default) always wins; otherwise an explicitly-set absolute
|
|
|
|
|
REM XDG_DATA_HOME (rare on Windows but honored the same way as the runtime;
|
|
|
|
|
REM drive-rooted or UNC) places the directory at XDG_DATA_HOME\plannotator;
|
|
|
|
|
REM otherwise %USERPROFILE%\.plannotator.
|
feat: add PLANNOTATOR_DATA_DIR env var to customize data directory (#795)
* feat: add PLANNOTATOR_DATA_DIR env var to customize data directory
* fix: update missed hardcoded paths to use PLANNOTATOR_DATA_DIR
OpenCode plugin and VS Code extension still used hardcoded
~/.plannotator paths, causing the IPC registry and plan backing
file to diverge from the server when PLANNOTATOR_DATA_DIR is set.
Also exports data-dir from @plannotator/shared and documents the
new env var in AGENTS.md.
Co-authored-by: Chris Werner Rau <14326070+cwrau@users.noreply.github.com>
Co-authored-by: João O. Santos <34689526+Joao-O-Santos@users.noreply.github.com>
* fix: vendor data-dir.ts into Pi extension and rewrite imports
The Pi extension copies shared/server modules into generated/ at
build time. Without vendoring data-dir.ts and rewriting the
parent-relative imports, typecheck fails on all generated files
that import getPlannotatorDataDir.
* refactor: eliminate duplicated data-dir logic and clean up call sites
- VS Code extension: replace inlined getPlannotatorDataDir() copy with
import from the canonical packages/shared/data-dir.ts (esbuild bundles
it, so no runtime dependency needed)
- storage.ts: hoist repeated getPlannotatorDataDir() calls to a
module-level DATA_DIR constant, matching the pattern config.ts uses
- data-dir.ts: remove inaccurate docstring claim about relative path
resolution (the code does not call resolve())
- improvement-hooks.ts: hoist to DATA_DIR constant, clarify comments
on the two-level hook lookup (hooks/ subdir vs root fallback)
* fix: resolve relative PLANNOTATOR_DATA_DIR to absolute path
A relative value like ./data would break readArchivedPlan's path
traversal guard, which compares a resolve()'d absolute path against
the still-relative planDir prefix. Always return an absolute path
so all callers get consistent path shapes.
* fix: use @plannotator/shared/data-dir imports in server package
Switch from relative ../shared/data-dir imports to the package
export, matching the convention every other server file follows.
Update Pi vendor script sed rules to match the new import style.
* fix: use package imports in server and respect data dir in compound skill
Server modules: switch from relative ../shared/data-dir imports to
@plannotator/shared/data-dir, matching the convention every other
server file follows. Update Pi vendor script sed rules to match.
Compound skill: update hardcoded ~/.plannotator paths to check
PLANNOTATOR_DATA_DIR first, so the skill reads plans and writes
the improvement hook to the correct location when users set a
custom data directory.
Co-authored-by: Chris Werner Rau <14326070+cwrau@users.noreply.github.com>
Co-authored-by: João O. Santos <34689526+Joao-O-Santos@users.noreply.github.com>
* fix: remove remaining hardcoded ~/.plannotator assumptions
- Settings UI: replace hardcoded path in label and placeholder with
generic text that doesn't assume a specific data directory
- quickLabels: update agent tip to reference PLANNOTATOR_DATA_DIR
so the agent checks the correct plans directory
- codex-review: hoist getPlannotatorDataDir() to module-level DATA_DIR
constant, eliminating redundant per-call resolution in debugLog()
- Tests: make submit-plan and storage tests resilient to
PLANNOTATOR_DATA_DIR being set in the environment
- Install scripts (sh, ps1, cmd): check PLANNOTATOR_DATA_DIR before
falling back to ~/.plannotator for config.json attestation lookup
* fix: expand tilde in install script and update test assertions
install.sh: PLANNOTATOR_DATA_DIR set to ~/... stays literal inside
double quotes, so the config file check silently failed. Add case
statement to expand ~ the same way the runtime data-dir.ts does.
install.test.ts: update three assertions that checked for hardcoded
~/.plannotator paths — now verify PLANNOTATOR_DATA_DIR awareness
instead.
* docs: add PLANNOTATOR_DATA_DIR to env var reference with VS Code note
Document the new env var on the marketing site's environment
variables reference page. Include a footnote about ensuring
VS Code inherits the variable when launched from the Dock.
---------
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
Co-authored-by: Chris Werner Rau <14326070+cwrau@users.noreply.github.com>
Co-authored-by: João O. Santos <34689526+Joao-O-Santos@users.noreply.github.com>
2026-05-27 05:56:07 +08:00
|
|
|
if defined PLANNOTATOR_DATA_DIR (
|
|
|
|
|
set "_CONFIG_DIR=!PLANNOTATOR_DATA_DIR!"
|
|
|
|
|
) else (
|
|
|
|
|
set "_CONFIG_DIR=%USERPROFILE%\.plannotator"
|
2026-07-20 08:55:12 -07:00
|
|
|
if not exist "%USERPROFILE%\.plannotator\" if defined XDG_DATA_HOME (
|
|
|
|
|
if "!XDG_DATA_HOME:~1,1!"==":" (
|
|
|
|
|
set "_CONFIG_DIR=!XDG_DATA_HOME!\plannotator"
|
|
|
|
|
) else if "!XDG_DATA_HOME:~0,2!"=="\\" (
|
|
|
|
|
set "_CONFIG_DIR=!XDG_DATA_HOME!\plannotator"
|
|
|
|
|
)
|
|
|
|
|
)
|
feat: add PLANNOTATOR_DATA_DIR env var to customize data directory (#795)
* feat: add PLANNOTATOR_DATA_DIR env var to customize data directory
* fix: update missed hardcoded paths to use PLANNOTATOR_DATA_DIR
OpenCode plugin and VS Code extension still used hardcoded
~/.plannotator paths, causing the IPC registry and plan backing
file to diverge from the server when PLANNOTATOR_DATA_DIR is set.
Also exports data-dir from @plannotator/shared and documents the
new env var in AGENTS.md.
Co-authored-by: Chris Werner Rau <14326070+cwrau@users.noreply.github.com>
Co-authored-by: João O. Santos <34689526+Joao-O-Santos@users.noreply.github.com>
* fix: vendor data-dir.ts into Pi extension and rewrite imports
The Pi extension copies shared/server modules into generated/ at
build time. Without vendoring data-dir.ts and rewriting the
parent-relative imports, typecheck fails on all generated files
that import getPlannotatorDataDir.
* refactor: eliminate duplicated data-dir logic and clean up call sites
- VS Code extension: replace inlined getPlannotatorDataDir() copy with
import from the canonical packages/shared/data-dir.ts (esbuild bundles
it, so no runtime dependency needed)
- storage.ts: hoist repeated getPlannotatorDataDir() calls to a
module-level DATA_DIR constant, matching the pattern config.ts uses
- data-dir.ts: remove inaccurate docstring claim about relative path
resolution (the code does not call resolve())
- improvement-hooks.ts: hoist to DATA_DIR constant, clarify comments
on the two-level hook lookup (hooks/ subdir vs root fallback)
* fix: resolve relative PLANNOTATOR_DATA_DIR to absolute path
A relative value like ./data would break readArchivedPlan's path
traversal guard, which compares a resolve()'d absolute path against
the still-relative planDir prefix. Always return an absolute path
so all callers get consistent path shapes.
* fix: use @plannotator/shared/data-dir imports in server package
Switch from relative ../shared/data-dir imports to the package
export, matching the convention every other server file follows.
Update Pi vendor script sed rules to match the new import style.
* fix: use package imports in server and respect data dir in compound skill
Server modules: switch from relative ../shared/data-dir imports to
@plannotator/shared/data-dir, matching the convention every other
server file follows. Update Pi vendor script sed rules to match.
Compound skill: update hardcoded ~/.plannotator paths to check
PLANNOTATOR_DATA_DIR first, so the skill reads plans and writes
the improvement hook to the correct location when users set a
custom data directory.
Co-authored-by: Chris Werner Rau <14326070+cwrau@users.noreply.github.com>
Co-authored-by: João O. Santos <34689526+Joao-O-Santos@users.noreply.github.com>
* fix: remove remaining hardcoded ~/.plannotator assumptions
- Settings UI: replace hardcoded path in label and placeholder with
generic text that doesn't assume a specific data directory
- quickLabels: update agent tip to reference PLANNOTATOR_DATA_DIR
so the agent checks the correct plans directory
- codex-review: hoist getPlannotatorDataDir() to module-level DATA_DIR
constant, eliminating redundant per-call resolution in debugLog()
- Tests: make submit-plan and storage tests resilient to
PLANNOTATOR_DATA_DIR being set in the environment
- Install scripts (sh, ps1, cmd): check PLANNOTATOR_DATA_DIR before
falling back to ~/.plannotator for config.json attestation lookup
* fix: expand tilde in install script and update test assertions
install.sh: PLANNOTATOR_DATA_DIR set to ~/... stays literal inside
double quotes, so the config file check silently failed. Add case
statement to expand ~ the same way the runtime data-dir.ts does.
install.test.ts: update three assertions that checked for hardcoded
~/.plannotator paths — now verify PLANNOTATOR_DATA_DIR awareness
instead.
* docs: add PLANNOTATOR_DATA_DIR to env var reference with VS Code note
Document the new env var on the marketing site's environment
variables reference page. Include a footnote about ensuring
VS Code inherits the variable when launched from the Dock.
---------
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
Co-authored-by: Chris Werner Rau <14326070+cwrau@users.noreply.github.com>
Co-authored-by: João O. Santos <34689526+Joao-O-Santos@users.noreply.github.com>
2026-05-27 05:56:07 +08:00
|
|
|
)
|
2026-05-27 21:49:30 -07:00
|
|
|
if /i "!_CONFIG_DIR!"=="~" set "_CONFIG_DIR=%USERPROFILE%"
|
|
|
|
|
if "!_CONFIG_DIR:~0,2!"=="~\" set "_CONFIG_DIR=%USERPROFILE%\!_CONFIG_DIR:~2!"
|
|
|
|
|
if "!_CONFIG_DIR:~0,2!"=="~/" set "_CONFIG_DIR=%USERPROFILE%\!_CONFIG_DIR:~2!"
|
feat: add PLANNOTATOR_DATA_DIR env var to customize data directory (#795)
* feat: add PLANNOTATOR_DATA_DIR env var to customize data directory
* fix: update missed hardcoded paths to use PLANNOTATOR_DATA_DIR
OpenCode plugin and VS Code extension still used hardcoded
~/.plannotator paths, causing the IPC registry and plan backing
file to diverge from the server when PLANNOTATOR_DATA_DIR is set.
Also exports data-dir from @plannotator/shared and documents the
new env var in AGENTS.md.
Co-authored-by: Chris Werner Rau <14326070+cwrau@users.noreply.github.com>
Co-authored-by: João O. Santos <34689526+Joao-O-Santos@users.noreply.github.com>
* fix: vendor data-dir.ts into Pi extension and rewrite imports
The Pi extension copies shared/server modules into generated/ at
build time. Without vendoring data-dir.ts and rewriting the
parent-relative imports, typecheck fails on all generated files
that import getPlannotatorDataDir.
* refactor: eliminate duplicated data-dir logic and clean up call sites
- VS Code extension: replace inlined getPlannotatorDataDir() copy with
import from the canonical packages/shared/data-dir.ts (esbuild bundles
it, so no runtime dependency needed)
- storage.ts: hoist repeated getPlannotatorDataDir() calls to a
module-level DATA_DIR constant, matching the pattern config.ts uses
- data-dir.ts: remove inaccurate docstring claim about relative path
resolution (the code does not call resolve())
- improvement-hooks.ts: hoist to DATA_DIR constant, clarify comments
on the two-level hook lookup (hooks/ subdir vs root fallback)
* fix: resolve relative PLANNOTATOR_DATA_DIR to absolute path
A relative value like ./data would break readArchivedPlan's path
traversal guard, which compares a resolve()'d absolute path against
the still-relative planDir prefix. Always return an absolute path
so all callers get consistent path shapes.
* fix: use @plannotator/shared/data-dir imports in server package
Switch from relative ../shared/data-dir imports to the package
export, matching the convention every other server file follows.
Update Pi vendor script sed rules to match the new import style.
* fix: use package imports in server and respect data dir in compound skill
Server modules: switch from relative ../shared/data-dir imports to
@plannotator/shared/data-dir, matching the convention every other
server file follows. Update Pi vendor script sed rules to match.
Compound skill: update hardcoded ~/.plannotator paths to check
PLANNOTATOR_DATA_DIR first, so the skill reads plans and writes
the improvement hook to the correct location when users set a
custom data directory.
Co-authored-by: Chris Werner Rau <14326070+cwrau@users.noreply.github.com>
Co-authored-by: João O. Santos <34689526+Joao-O-Santos@users.noreply.github.com>
* fix: remove remaining hardcoded ~/.plannotator assumptions
- Settings UI: replace hardcoded path in label and placeholder with
generic text that doesn't assume a specific data directory
- quickLabels: update agent tip to reference PLANNOTATOR_DATA_DIR
so the agent checks the correct plans directory
- codex-review: hoist getPlannotatorDataDir() to module-level DATA_DIR
constant, eliminating redundant per-call resolution in debugLog()
- Tests: make submit-plan and storage tests resilient to
PLANNOTATOR_DATA_DIR being set in the environment
- Install scripts (sh, ps1, cmd): check PLANNOTATOR_DATA_DIR before
falling back to ~/.plannotator for config.json attestation lookup
* fix: expand tilde in install script and update test assertions
install.sh: PLANNOTATOR_DATA_DIR set to ~/... stays literal inside
double quotes, so the config file check silently failed. Add case
statement to expand ~ the same way the runtime data-dir.ts does.
install.test.ts: update three assertions that checked for hardcoded
~/.plannotator paths — now verify PLANNOTATOR_DATA_DIR awareness
instead.
* docs: add PLANNOTATOR_DATA_DIR to env var reference with VS Code note
Document the new env var on the marketing site's environment
variables reference page. Include a footnote about ensuring
VS Code inherits the variable when launched from the Dock.
---------
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
Co-authored-by: Chris Werner Rau <14326070+cwrau@users.noreply.github.com>
Co-authored-by: João O. Santos <34689526+Joao-O-Santos@users.noreply.github.com>
2026-05-27 05:56:07 +08:00
|
|
|
if exist "!_CONFIG_DIR!\config.json" (
|
|
|
|
|
findstr /r /c:"\"verifyAttestation\"[ ]*:[ ]*true" "!_CONFIG_DIR!\config.json" >nul 2>&1
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
if !ERRORLEVEL! equ 0 set "VERIFY_ATTESTATION=1"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
REM Layer 2: env var (overrides config file).
|
|
|
|
|
if /i "!PLANNOTATOR_VERIFY_ATTESTATION!"=="1" set "VERIFY_ATTESTATION=1"
|
|
|
|
|
if /i "!PLANNOTATOR_VERIFY_ATTESTATION!"=="true" set "VERIFY_ATTESTATION=1"
|
|
|
|
|
if /i "!PLANNOTATOR_VERIFY_ATTESTATION!"=="yes" set "VERIFY_ATTESTATION=1"
|
|
|
|
|
if /i "!PLANNOTATOR_VERIFY_ATTESTATION!"=="0" set "VERIFY_ATTESTATION=0"
|
|
|
|
|
if /i "!PLANNOTATOR_VERIFY_ATTESTATION!"=="false" set "VERIFY_ATTESTATION=0"
|
|
|
|
|
if /i "!PLANNOTATOR_VERIFY_ATTESTATION!"=="no" set "VERIFY_ATTESTATION=0"
|
|
|
|
|
|
|
|
|
|
REM Layer 1: CLI flag (overrides everything).
|
|
|
|
|
if "!VERIFY_ATTESTATION_FLAG!"=="1" set "VERIFY_ATTESTATION=1"
|
|
|
|
|
if "!VERIFY_ATTESTATION_FLAG!"=="0" set "VERIFY_ATTESTATION=0"
|
|
|
|
|
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM Resolve the per-agent integration opt-outs (#1178). Same three-layer shape
|
|
|
|
|
REM as verifyAttestation: CLI flag > env var > config skipInstall.<agent> >
|
|
|
|
|
REM default (off). The config layer parses the REAL JSON with PowerShell
|
|
|
|
|
REM (M2): findstr is line-oblivious, so a "codex": true under some OTHER key
|
|
|
|
|
REM would have opted users out, and an explicit false inside skipInstall
|
|
|
|
|
REM would have been ignored. PowerShell reads the actual skipInstall object
|
|
|
|
|
REM (strict boolean check, matching install.ps1) and emits one agent name
|
|
|
|
|
REM per enabled skip; the config path travels via an env var so nothing is
|
|
|
|
|
REM re-parsed as code. Each resolved skip remembers its source so the
|
|
|
|
|
REM detected-but-skipped report can name what the user set.
|
|
|
|
|
set "SKIP_CODEX=0"
|
|
|
|
|
set "SKIP_CODEX_SOURCE="
|
|
|
|
|
set "SKIP_GEMINI=0"
|
|
|
|
|
set "SKIP_GEMINI_SOURCE="
|
|
|
|
|
set "SKIP_KIRO=0"
|
|
|
|
|
set "SKIP_KIRO_SOURCE="
|
|
|
|
|
set "SKIP_OPENCODE=0"
|
|
|
|
|
set "SKIP_OPENCODE_SOURCE="
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
REM skipInstall.skills is not an agent - it opts out of the skills/slash-command
|
|
|
|
|
REM checkout for every scope at once - but it shares the same three layers.
|
|
|
|
|
set "SKIP_SKILLS=0"
|
|
|
|
|
set "SKIP_SKILLS_SOURCE="
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
if exist "!_CONFIG_DIR!\config.json" (
|
|
|
|
|
set "PLN_CONFIG_JSON=!_CONFIG_DIR!\config.json"
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
for /f "usebackq delims=" %%K in (`powershell -NoProfile -Command "try { $c = Get-Content $env:PLN_CONFIG_JSON -Raw | ConvertFrom-Json } catch { exit 0 }; if (-not $c.skipInstall) { exit 0 }; foreach ($k in @('codex','gemini','kiro','opencode','skills')) { $v = $c.skipInstall.$k; if ($v -is [bool] -and $v) { $k } }"`) do (
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
if /i "%%K"=="codex" (
|
|
|
|
|
set "SKIP_CODEX=1"
|
|
|
|
|
set "SKIP_CODEX_SOURCE=config skipInstall.codex"
|
|
|
|
|
)
|
|
|
|
|
if /i "%%K"=="gemini" (
|
|
|
|
|
set "SKIP_GEMINI=1"
|
|
|
|
|
set "SKIP_GEMINI_SOURCE=config skipInstall.gemini"
|
|
|
|
|
)
|
|
|
|
|
if /i "%%K"=="kiro" (
|
|
|
|
|
set "SKIP_KIRO=1"
|
|
|
|
|
set "SKIP_KIRO_SOURCE=config skipInstall.kiro"
|
|
|
|
|
)
|
|
|
|
|
if /i "%%K"=="opencode" (
|
|
|
|
|
set "SKIP_OPENCODE=1"
|
|
|
|
|
set "SKIP_OPENCODE_SOURCE=config skipInstall.opencode"
|
|
|
|
|
)
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
if /i "%%K"=="skills" (
|
|
|
|
|
set "SKIP_SKILLS=1"
|
|
|
|
|
set "SKIP_SKILLS_SOURCE=config skipInstall.skills"
|
|
|
|
|
)
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
)
|
|
|
|
|
set "PLN_CONFIG_JSON="
|
|
|
|
|
)
|
|
|
|
|
for %%V in (1 true yes) do if /i "!PLANNOTATOR_SKIP_CODEX_INSTALL!"=="%%V" (
|
|
|
|
|
set "SKIP_CODEX=1"
|
|
|
|
|
set "SKIP_CODEX_SOURCE=PLANNOTATOR_SKIP_CODEX_INSTALL"
|
|
|
|
|
)
|
|
|
|
|
for %%V in (0 false no) do if /i "!PLANNOTATOR_SKIP_CODEX_INSTALL!"=="%%V" (
|
|
|
|
|
set "SKIP_CODEX=0"
|
|
|
|
|
set "SKIP_CODEX_SOURCE="
|
|
|
|
|
)
|
|
|
|
|
for %%V in (1 true yes) do if /i "!PLANNOTATOR_SKIP_GEMINI_INSTALL!"=="%%V" (
|
|
|
|
|
set "SKIP_GEMINI=1"
|
|
|
|
|
set "SKIP_GEMINI_SOURCE=PLANNOTATOR_SKIP_GEMINI_INSTALL"
|
|
|
|
|
)
|
|
|
|
|
for %%V in (0 false no) do if /i "!PLANNOTATOR_SKIP_GEMINI_INSTALL!"=="%%V" (
|
|
|
|
|
set "SKIP_GEMINI=0"
|
|
|
|
|
set "SKIP_GEMINI_SOURCE="
|
|
|
|
|
)
|
|
|
|
|
for %%V in (1 true yes) do if /i "!PLANNOTATOR_SKIP_KIRO_INSTALL!"=="%%V" (
|
|
|
|
|
set "SKIP_KIRO=1"
|
|
|
|
|
set "SKIP_KIRO_SOURCE=PLANNOTATOR_SKIP_KIRO_INSTALL"
|
|
|
|
|
)
|
|
|
|
|
for %%V in (0 false no) do if /i "!PLANNOTATOR_SKIP_KIRO_INSTALL!"=="%%V" (
|
|
|
|
|
set "SKIP_KIRO=0"
|
|
|
|
|
set "SKIP_KIRO_SOURCE="
|
|
|
|
|
)
|
|
|
|
|
for %%V in (1 true yes) do if /i "!PLANNOTATOR_SKIP_OPENCODE_INSTALL!"=="%%V" (
|
|
|
|
|
set "SKIP_OPENCODE=1"
|
|
|
|
|
set "SKIP_OPENCODE_SOURCE=PLANNOTATOR_SKIP_OPENCODE_INSTALL"
|
|
|
|
|
)
|
|
|
|
|
for %%V in (0 false no) do if /i "!PLANNOTATOR_SKIP_OPENCODE_INSTALL!"=="%%V" (
|
|
|
|
|
set "SKIP_OPENCODE=0"
|
|
|
|
|
set "SKIP_OPENCODE_SOURCE="
|
|
|
|
|
)
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
for %%V in (1 true yes) do if /i "!PLANNOTATOR_SKIP_SKILLS_INSTALL!"=="%%V" (
|
|
|
|
|
set "SKIP_SKILLS=1"
|
|
|
|
|
set "SKIP_SKILLS_SOURCE=PLANNOTATOR_SKIP_SKILLS_INSTALL"
|
|
|
|
|
)
|
|
|
|
|
for %%V in (0 false no) do if /i "!PLANNOTATOR_SKIP_SKILLS_INSTALL!"=="%%V" (
|
|
|
|
|
set "SKIP_SKILLS=0"
|
|
|
|
|
set "SKIP_SKILLS_SOURCE="
|
|
|
|
|
)
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
if "!SKIP_CODEX_FLAG!"=="1" (
|
|
|
|
|
set "SKIP_CODEX=1"
|
|
|
|
|
set "SKIP_CODEX_SOURCE=--skip-codex"
|
|
|
|
|
)
|
|
|
|
|
if "!SKIP_GEMINI_FLAG!"=="1" (
|
|
|
|
|
set "SKIP_GEMINI=1"
|
|
|
|
|
set "SKIP_GEMINI_SOURCE=--skip-gemini"
|
|
|
|
|
)
|
|
|
|
|
if "!SKIP_KIRO_FLAG!"=="1" (
|
|
|
|
|
set "SKIP_KIRO=1"
|
|
|
|
|
set "SKIP_KIRO_SOURCE=--skip-kiro"
|
|
|
|
|
)
|
|
|
|
|
if "!SKIP_OPENCODE_FLAG!"=="1" (
|
|
|
|
|
set "SKIP_OPENCODE=1"
|
|
|
|
|
set "SKIP_OPENCODE_SOURCE=--skip-opencode"
|
|
|
|
|
)
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
if "!SKIP_SKILLS_FLAG!"=="1" (
|
|
|
|
|
set "SKIP_SKILLS=1"
|
|
|
|
|
set "SKIP_SKILLS_SOURCE=--skip-skills"
|
|
|
|
|
)
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM Pre-flight: reject verification requests for tags older than the first
|
|
|
|
|
REM attested release BEFORE downloading. Critical security point: the version
|
|
|
|
|
REM comparison uses $env:TAG_NUM / $env:MIN_NUM instead of interpolating
|
|
|
|
|
REM !TAG_NUM! / !MIN_NUM! into the PowerShell command string. Interpolation
|
|
|
|
|
REM would let a crafted --version value break out of the single-quoted literal
|
|
|
|
|
REM and execute arbitrary PowerShell (e.g. --version "0.18.0'; calc; '0.18.0"
|
|
|
|
|
REM would run Calculator). $env: reads the raw string; PowerShell never parses
|
|
|
|
|
REM the value as code. [version] cast throws on invalid input, catch swallows,
|
2026-07-10 06:50:40 -07:00
|
|
|
REM VERSION_OK stays empty, and the guard rejects - safe fail.
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
if "!VERIFY_ATTESTATION!"=="1" (
|
|
|
|
|
REM Strip the leading `v` via substring-from-index-1. cmd's `:str=repl`
|
2026-07-10 06:50:40 -07:00
|
|
|
REM substitution is GLOBAL, not anchored - `!TAG:v=!` would remove every
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM `v` in the string, not just the leading one, so a hypothetical tag
|
|
|
|
|
REM like `v1.0.0-rev2` would become `1.0.0-re2` and break the [version]
|
|
|
|
|
REM cast. TAG is guaranteed to start with `v` by the normalization step
|
|
|
|
|
REM above, so `:~1` (drop first char) is equivalent to stripping the
|
|
|
|
|
REM leading prefix.
|
|
|
|
|
set "TAG_NUM=!TAG:~1!"
|
|
|
|
|
set "MIN_NUM=!MIN_ATTESTED_VERSION:~1!"
|
|
|
|
|
|
|
|
|
|
REM Detect pre-release / build-metadata tags (e.g. v0.18.0-rc1) BEFORE
|
|
|
|
|
REM handing the value to PowerShell. [System.Version] doesn't support
|
|
|
|
|
REM semver prerelease suffixes and would throw inside the try/catch,
|
|
|
|
|
REM leaving VERSION_OK empty and surfacing a misleading "predates
|
|
|
|
|
REM attestation support" error. install.sh handles these correctly via
|
|
|
|
|
REM `sort -V`; Windows doesn't have a built-in semver comparator, so
|
|
|
|
|
REM we reject explicitly with an accurate diagnosis instead of silently
|
|
|
|
|
REM misclassifying the failure.
|
|
|
|
|
REM
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Uses native cmd substitution `!VAR:-=!` to check for `-` presence -
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM no subshell, no metacharacter risk. If removing `-` changes the
|
|
|
|
|
REM string, the original contained a `-`.
|
|
|
|
|
if not "!TAG_NUM!"=="!TAG_NUM:-=!" (
|
|
|
|
|
echo Pre-release tags like !TAG! aren't currently supported for >&2
|
|
|
|
|
echo provenance verification on Windows. [System.Version] doesn't >&2
|
|
|
|
|
echo parse semver prerelease suffixes. Options: >&2
|
|
|
|
|
echo - Install without provenance verification: --skip-attestation >&2
|
|
|
|
|
echo - Pin to a stable release tag ^(no `-rc`, `-beta`, etc.^) >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
set "VERSION_OK="
|
|
|
|
|
for /f "delims=" %%i in ('powershell -NoProfile -Command "try { if ([version]$env:TAG_NUM -ge [version]$env:MIN_NUM) { 'yes' } } catch {}"') do set "VERSION_OK=%%i"
|
|
|
|
|
if not "!VERSION_OK!"=="yes" (
|
|
|
|
|
echo Provenance verification was requested, but !TAG! predates >&2
|
|
|
|
|
echo plannotator's attestation support. The first release carrying >&2
|
|
|
|
|
echo signed build provenance is !MIN_ATTESTED_VERSION!. Options: >&2
|
|
|
|
|
echo - Pin to !MIN_ATTESTED_VERSION! or later: --version !MIN_ATTESTED_VERSION! >&2
|
|
|
|
|
echo - Install without provenance verification: --skip-attestation >&2
|
|
|
|
|
echo - Or unset PLANNOTATOR_VERIFY_ATTESTATION / remove verifyAttestation >&2
|
|
|
|
|
echo from %USERPROFILE%\.plannotator\config.json >&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
2025-12-28 14:44:54 -08:00
|
|
|
set "BINARY_NAME=plannotator-!PLATFORM!.exe"
|
|
|
|
|
set "BINARY_URL=https://github.com/!REPO!/releases/download/!TAG!/!BINARY_NAME!"
|
|
|
|
|
set "CHECKSUM_URL=!BINARY_URL!.sha256"
|
|
|
|
|
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM Download binary to a randomized temp path so concurrent invocations
|
|
|
|
|
REM don't collide and a same-user pre-placed symlink at a predictable
|
|
|
|
|
REM path can't redirect where curl writes the downloaded executable.
|
|
|
|
|
REM The SHA256 check would pass regardless (content is authentic), but
|
|
|
|
|
REM the install destination would be corrupted.
|
|
|
|
|
set "TEMP_FILE=%TEMP%\plannotator-%RANDOM%.exe"
|
2025-12-28 14:44:54 -08:00
|
|
|
curl -fsSL "!BINARY_URL!" -o "!TEMP_FILE!"
|
|
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
echo Failed to download binary >&2
|
|
|
|
|
if exist "!TEMP_FILE!" del "!TEMP_FILE!"
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM Download checksum to a randomized temp path for the same reason as
|
|
|
|
|
REM the binary download above (concurrent collision + symlink pre-placement).
|
|
|
|
|
set "CHECKSUM_FILE=%TEMP%\plannotator-checksum-%RANDOM%.txt"
|
|
|
|
|
curl -fsSL "!CHECKSUM_URL!" -o "!CHECKSUM_FILE!"
|
2025-12-28 14:44:54 -08:00
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
echo Failed to download checksum >&2
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM curl -o creates the output file before receiving data, so a
|
|
|
|
|
REM network failure or HTTP error leaves a 0-byte/partial file
|
|
|
|
|
REM at CHECKSUM_FILE. Clean it up to match the discipline used
|
|
|
|
|
REM for TEMP_FILE elsewhere in this script.
|
|
|
|
|
if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"
|
2025-12-28 14:44:54 -08:00
|
|
|
del "!TEMP_FILE!"
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
REM Extract expected checksum (first field)
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
set /p EXPECTED_CHECKSUM=<"!CHECKSUM_FILE!"
|
2025-12-28 14:44:54 -08:00
|
|
|
for /f "tokens=1" %%i in ("!EXPECTED_CHECKSUM!") do set "EXPECTED_CHECKSUM=%%i"
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
del "!CHECKSUM_FILE!"
|
2025-12-28 14:44:54 -08:00
|
|
|
|
|
|
|
|
REM Verify checksum using certutil
|
|
|
|
|
set "ACTUAL_CHECKSUM="
|
|
|
|
|
for /f "skip=1 tokens=*" %%i in ('certutil -hashfile "!TEMP_FILE!" SHA256') do (
|
|
|
|
|
if not defined ACTUAL_CHECKSUM (
|
|
|
|
|
set "ACTUAL_CHECKSUM=%%i"
|
|
|
|
|
set "ACTUAL_CHECKSUM=!ACTUAL_CHECKSUM: =!"
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
if /i "!ACTUAL_CHECKSUM!" neq "!EXPECTED_CHECKSUM!" (
|
|
|
|
|
echo Checksum verification failed >&2
|
|
|
|
|
del "!TEMP_FILE!"
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
if "!VERIFY_ATTESTATION!"=="1" (
|
|
|
|
|
REM VERIFY_ATTESTATION was resolved before the download; MIN_ATTESTED_VERSION
|
|
|
|
|
REM pre-flight already ran and rejected older tags. At this point we know
|
|
|
|
|
REM the tag is attested and gh should find a bundle.
|
|
|
|
|
where gh >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 (
|
|
|
|
|
REM Capture combined output to a randomized temp file so gh's
|
|
|
|
|
REM actual error message (auth, network, missing attestation, etc.)
|
|
|
|
|
REM can be surfaced on failure. Randomized to match the existing
|
|
|
|
|
REM %RANDOM% pattern used elsewhere in this script and avoid races
|
|
|
|
|
REM between concurrent invocations. Matches install.sh / install.ps1.
|
|
|
|
|
REM
|
|
|
|
|
REM Verification is constrained to the exact tag (--source-ref) AND
|
2026-07-10 06:50:40 -07:00
|
|
|
REM the specific signing workflow file (--signer-workflow) - not
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
REM just "built somewhere in this repo". See install.sh for full
|
|
|
|
|
REM rationale.
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM Credential-free path first (#1178): the attestations endpoint on
|
|
|
|
|
REM api.github.com is world-readable for public repos, so fetch the
|
|
|
|
|
REM Sigstore bundle anonymously and hand it to gh via --bundle. This
|
|
|
|
|
REM drops the gh-login requirement; gh's own authenticated fetch is
|
|
|
|
|
REM only used as a fallback when the public fetch fails. Single fetch
|
|
|
|
|
REM attempt, deliberately never retried: the unauthenticated API
|
|
|
|
|
REM allows 60 requests/hour per IP. The response is
|
|
|
|
|
REM { "attestations": [ { "bundle": {...} } ] }; gh --bundle expects
|
|
|
|
|
REM the bundle values one JSON document per line (the JSONL format
|
|
|
|
|
REM `gh attestation download` writes). PowerShell does the fetch and
|
|
|
|
|
REM the extraction via the ATT_FETCH_B64 -EncodedCommand payload
|
|
|
|
|
REM (documented and drift-guarded where it is defined, near the top
|
|
|
|
|
REM of this file): each bundle is copied as a byte-exact substring of
|
|
|
|
|
REM the response, never a ConvertFrom-Json round trip whose DateTime
|
|
|
|
|
REM coercion could corrupt a bundle field. Values pass via $env: so
|
|
|
|
|
REM nothing is re-parsed as code, and no helper file ever exists on
|
|
|
|
|
REM disk. Exit codes: 0 = bundle written, 2 = fetch failed, 3 = no
|
|
|
|
|
REM bundle extracted.
|
|
|
|
|
set "ATT_BUNDLE_FILE=%TEMP%\plannotator-bundle-%RANDOM%.jsonl"
|
|
|
|
|
set "ATT_DIGEST=!ACTUAL_CHECKSUM!"
|
|
|
|
|
set "ATT_BUNDLE_OK=0"
|
|
|
|
|
REM NOTE: the ATT_FALLBACK_REASON literals below are assigned inside
|
|
|
|
|
REM parenthesized blocks - they must stay free of unescaped cmd
|
|
|
|
|
REM metacharacters, parentheses above all, or the block parse breaks.
|
|
|
|
|
set "ATT_FALLBACK_REASON=Could not fetch the attestation bundle from the public API"
|
|
|
|
|
powershell -NoProfile -EncodedCommand !ATT_FETCH_B64!
|
|
|
|
|
if !ERRORLEVEL! equ 0 (
|
|
|
|
|
if exist "!ATT_BUNDLE_FILE!" set "ATT_BUNDLE_OK=1"
|
|
|
|
|
) else if !ERRORLEVEL! equ 3 (
|
|
|
|
|
set "ATT_FALLBACK_REASON=Could not extract a bundle from the attestations API response"
|
|
|
|
|
)
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
set "GH_OUTPUT=%TEMP%\plannotator-gh-%RANDOM%.txt"
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
set "ATT_USED_BUNDLE=0"
|
|
|
|
|
if "!ATT_BUNDLE_OK!"=="1" (
|
|
|
|
|
set "ATT_USED_BUNDLE=1"
|
|
|
|
|
gh attestation verify "!TEMP_FILE!" ^
|
|
|
|
|
--bundle "!ATT_BUNDLE_FILE!" ^
|
|
|
|
|
--repo "!REPO!" ^
|
|
|
|
|
--source-ref "refs/tags/!TAG!" ^
|
|
|
|
|
--signer-workflow "backnotprop/plannotator/.github/workflows/release.yml" ^
|
|
|
|
|
> "!GH_OUTPUT!" 2>&1
|
|
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
REM H1: a --bundle failure is not necessarily a provenance
|
|
|
|
|
REM failure - an older gh rejects the flag outright, a corrupt
|
|
|
|
|
REM bundle fails parsing, etc. Retry once through the exact
|
|
|
|
|
REM authenticated path before classifying anything; only the
|
|
|
|
|
REM retry's verdict is reported. A real provenance failure
|
|
|
|
|
REM fails again here, so nothing bad ever slips through.
|
|
|
|
|
echo Bundle-based verification did not complete; retrying via gh's authenticated fetch.
|
|
|
|
|
set "ATT_USED_BUNDLE=0"
|
|
|
|
|
gh attestation verify "!TEMP_FILE!" ^
|
|
|
|
|
--repo "!REPO!" ^
|
|
|
|
|
--source-ref "refs/tags/!TAG!" ^
|
|
|
|
|
--signer-workflow "backnotprop/plannotator/.github/workflows/release.yml" ^
|
|
|
|
|
> "!GH_OUTPUT!" 2>&1
|
|
|
|
|
)
|
|
|
|
|
) else (
|
|
|
|
|
echo !ATT_FALLBACK_REASON!; falling back to gh's authenticated fetch.
|
|
|
|
|
gh attestation verify "!TEMP_FILE!" ^
|
|
|
|
|
--repo "!REPO!" ^
|
|
|
|
|
--source-ref "refs/tags/!TAG!" ^
|
|
|
|
|
--signer-workflow "backnotprop/plannotator/.github/workflows/release.yml" ^
|
|
|
|
|
> "!GH_OUTPUT!" 2>&1
|
|
|
|
|
)
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
type "!GH_OUTPUT!" >&2
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM Classify the failure so connectivity problems are never
|
|
|
|
|
REM conflated with a provenance failure. "Sigstore verifiers"
|
|
|
|
|
REM means gh could not initialize the TUF trust root, which is
|
|
|
|
|
REM fetched on EVERY run (never cached); "gh auth login" is only
|
|
|
|
|
REM reachable on the authenticated path. Precedence: TUF wins
|
|
|
|
|
REM over auth (the auth findstr runs first so the TUF assignment
|
|
|
|
|
REM lands last, matching install.sh / install.ps1).
|
|
|
|
|
set "VERIFY_FAIL_KIND=provenance"
|
|
|
|
|
findstr /c:"gh auth login" "!GH_OUTPUT!" >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 set "VERIFY_FAIL_KIND=auth"
|
|
|
|
|
findstr /c:"Sigstore verifiers" "!GH_OUTPUT!" >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 set "VERIFY_FAIL_KIND=tuf"
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
del "!GH_OUTPUT!"
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
if exist "!ATT_BUNDLE_FILE!" del "!ATT_BUNDLE_FILE!"
|
|
|
|
|
if "!VERIFY_FAIL_KIND!"=="tuf" (
|
|
|
|
|
echo Could not initialize the Sigstore trust root ^(TUF^). Provenance >&2
|
|
|
|
|
echo verification needs network access on every run; the trusted root >&2
|
|
|
|
|
echo is fetched per-run, never cached. This is a connectivity failure, >&2
|
|
|
|
|
echo NOT evidence of a bad binary. Refusing to install unverified; >&2
|
|
|
|
|
echo retry with network access or pass --skip-attestation. >&2
|
|
|
|
|
)
|
|
|
|
|
if "!VERIFY_FAIL_KIND!"=="auth" (
|
|
|
|
|
echo The credential-free bundle path did not complete and gh is not >&2
|
|
|
|
|
echo logged in, so the authenticated fallback could not run. Retry with >&2
|
|
|
|
|
echo network access to api.github.com, run 'gh auth login', or pass >&2
|
|
|
|
|
echo --skip-attestation. >&2
|
|
|
|
|
)
|
|
|
|
|
if "!VERIFY_FAIL_KIND!"=="provenance" (
|
|
|
|
|
echo Attestation verification failed! >&2
|
|
|
|
|
echo The binary's SHA256 matched, but no valid signed provenance was found >&2
|
|
|
|
|
echo for !REPO!. Refusing to install. >&2
|
|
|
|
|
)
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
del "!TEMP_FILE!"
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
del "!GH_OUTPUT!"
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
if "!ATT_USED_BUNDLE!"=="1" (
|
|
|
|
|
echo [OK] verified build provenance ^(SLSA, credential-free via the public attestations API^)
|
|
|
|
|
) else (
|
|
|
|
|
echo [OK] verified build provenance ^(SLSA^)
|
|
|
|
|
)
|
|
|
|
|
if exist "!ATT_BUNDLE_FILE!" del "!ATT_BUNDLE_FILE!"
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
) else (
|
|
|
|
|
echo verifyAttestation is enabled but gh CLI was not found. >&2
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
echo Install https://cli.github.com ^(no login is needed when the public >&2
|
|
|
|
|
echo attestation bundle fetch succeeds^), or unset >&2
|
|
|
|
|
echo PLANNOTATOR_VERIFY_ATTESTATION / remove verifyAttestation >&2
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
echo from %USERPROFILE%\.plannotator\config.json / pass --skip-attestation. >&2
|
|
|
|
|
del "!TEMP_FILE!"
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
) else (
|
|
|
|
|
echo SHA256 verified. For build provenance verification, see
|
2026-07-19 07:27:38 -07:00
|
|
|
echo https://docs.plannotator.ai/open-source/start/installation#pin-or-verify-a-release
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
)
|
|
|
|
|
|
2025-12-28 14:44:54 -08:00
|
|
|
REM Install binary
|
|
|
|
|
set "INSTALL_PATH=!INSTALL_DIR!\plannotator.exe"
|
|
|
|
|
move /y "!TEMP_FILE!" "!INSTALL_PATH!" >nul
|
|
|
|
|
|
|
|
|
|
echo.
|
|
|
|
|
echo plannotator !TAG! installed to !INSTALL_PATH!
|
|
|
|
|
|
feat(install): add --minimal binary-only install mode (#989)
* feat(install): add --minimal binary-only install mode
install.sh installs the plannotator binary and then writes a large amount
of extra state: the sem sidecar, the agent-terminal runtime, and per-agent
skills, hooks, slash commands, and config for Claude, Codex, OpenCode,
Gemini, and Kiro. There is no way to get just the binary — even the
--no-extras path still writes ~/.claude skills and OpenCode commands.
Add a --minimal flag (aliased --binary-only) plus a PLANNOTATOR_MINIMAL
env var for `curl | bash` runs. Minimal mode installs only the binary to
~/.local/bin, prints PATH advice, and exits before any sidecar download,
agent integration, skill checkout, config write, cache clear, or cleanup
migration. Precedence: flag > env var > default (off).
The PATH-advice block is extracted into print_path_advice() so both the
minimal early exit and the normal flow reuse it.
Closes #977
* feat(install): mirror minimal mode to ps1/cmd, add --no-minimal, docs
Extend the binary-only install mode to full cross-installer parity and
address the Copilot review on #989.
install.sh:
- Add --no-minimal (MINIMAL_FLAG=0) so a CLI flag can override
PLANNOTATOR_MINIMAL=1 in both directions; the -1/0/1 comment is now
accurate. --minimal/--no-minimal are mutually exclusive.
- Document the --binary-only alias and soften the absolute "nothing
written outside ..." wording to "no persistent state" (minimal mode
still uses a temp download file and may read the config dir).
install.ps1 / install.cmd:
- Add -Minimal (alias BinaryOnly)/-NoMinimal and --minimal/--binary-only/
--no-minimal with PLANNOTATOR_MINIMAL resolution, mirroring install.sh.
- Extract PATH advice into Show-PathAdvice / :PrintPathAdvice and reuse it
in both the minimal early exit and the normal flow.
- Early-exit after the binary is placed, before the sidecar/agent/skill/
config work.
Tests: add minimal-mode assertions to the install.ps1 and install.cmd
describe blocks plus a shared-behavior test asserting all three installers
support it; extend the sh tests for --no-minimal.
Docs: document --minimal / PLANNOTATOR_MINIMAL in the installation guide
(noting minimal mode needs no git) and add PLANNOTATOR_MINIMAL (and backfill
PLANNOTATOR_SKIP_SEM_INSTALL) to the env-var registries.
* docs(install): correct minimal-mode PATH wording (ps1 persists PATH)
The PowerShell installer's minimal path calls Show-PathAdvice, which
persistently writes the user PATH — so "no persistent state is written
outside $installDir" overpromised. Reword the install.ps1 comment and the
installation docs to describe what minimal mode skips (sidecar, agent
runtime, per-agent integrations) and note the binary + PATH entry are still
added on Windows. Addresses the second Copilot review on #989.
* fix(install.cmd): use delayed expansion for PLANNOTATOR_MINIMAL checks
The three new env-var checks used immediate %VAR% expansion; under
setlocal enabledelayedexpansion a poisoned value re-exposes cmd
metacharacters at parse time (command injection). Switch to the !VAR!
idiom the script already uses for every other untrusted env var (e.g.
the PLANNOTATOR_VERIFY_ATTESTATION block).
---------
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
2026-07-07 00:43:42 +02:00
|
|
|
REM Binary-only mode stops here (see the MINIMAL resolution after :args_done):
|
|
|
|
|
REM the binary is installed, so print PATH advice and exit before any sidecar
|
|
|
|
|
REM download, agent integration, skill checkout, or config write runs. No
|
|
|
|
|
REM persistent state is written outside !INSTALL_DIR!.
|
|
|
|
|
if "!MINIMAL!"=="1" (
|
|
|
|
|
call :PrintPathAdvice
|
|
|
|
|
echo.
|
|
|
|
|
echo Minimal install complete - only the plannotator binary was installed.
|
|
|
|
|
echo No skills, hooks, agent integrations, or config files were written.
|
|
|
|
|
exit /b 0
|
|
|
|
|
)
|
|
|
|
|
|
feat(review): add semantic diff overview (#871)
* feat(review): add semantic diff overview
* fix(review): address semantic diff review findings
* fix(review): harden semantic diff fallback
* fix(review): avoid repo-local sem execution
* fix(review): normalize semantic diff cwd
* test(review): cover semantic diff local cwd
* fix(gitlab): fetch raw MR diffs
* fix(review): harden sem path resolution
* docs(review): add semantic diff handoff
* feat(review): semantic diff cards, header sem badges, jump-to-line
- Restyle the semantic panel as real bordered cards (shadcn surface) instead
of ASCII box-drawing; centered column, grid-aligned entity rows.
- Hide orphan (module-level) changes from the rows, matching sem's default;
the count still surfaces in the summary line.
- Add a 'sem · N' hover popover to each diff file header showing that file's
semantic changes, reusing the same row component as the panel.
- Clicking an entity (panel or popover) scrolls the diff to the lines via
pierre's [data-selected-line]; centers only when off-screen so manual
drag-selection isn't disturbed.
- Extract shared rows/helpers into semanticDiffShared; share one cached
/api/semantic-diff fetch across header badges.
* feat(review): land on All files by default
Semantic diff stays available via the file-tree nav entry and header badges,
but it's no longer the initial landing view.
* chore(review): drop dead change-symbol entries, log badge fetch failures
- Remove unreachable 'moved'/'renamed' entries from the changeSymbols table
(getChangeSymbol early-returns for those before the lookup).
- Log a console.error once per patch when the file-header badge's semantic
diff fetch fails or returns a non-ok status, so a systemic failure leaves a
trace instead of every badge silently showing nothing.
* feat(review): flatten semantic diff panel into grouped list
- Dissolve the per-file bordered cards into flat sections: the file path is now
a quiet underlined header (single hairline) with entity rows flush beneath,
hierarchy from whitespace + hover tint instead of boxes.
- Split the path into muted directory + emphasized filename for faster scanning.
- Nudge the add/remove glyphs (⊕/⊖) ~15% larger, line-height pinned so rows
don't grow; modified/rename/reorder glyphs unchanged.
2026-06-08 22:23:54 -07:00
|
|
|
call :InstallSemSidecar
|
2026-06-19 09:04:15 -07:00
|
|
|
call :InstallAgentTerminalRuntime
|
feat(review): add semantic diff overview (#871)
* feat(review): add semantic diff overview
* fix(review): address semantic diff review findings
* fix(review): harden semantic diff fallback
* fix(review): avoid repo-local sem execution
* fix(review): normalize semantic diff cwd
* test(review): cover semantic diff local cwd
* fix(gitlab): fetch raw MR diffs
* fix(review): harden sem path resolution
* docs(review): add semantic diff handoff
* feat(review): semantic diff cards, header sem badges, jump-to-line
- Restyle the semantic panel as real bordered cards (shadcn surface) instead
of ASCII box-drawing; centered column, grid-aligned entity rows.
- Hide orphan (module-level) changes from the rows, matching sem's default;
the count still surfaces in the summary line.
- Add a 'sem · N' hover popover to each diff file header showing that file's
semantic changes, reusing the same row component as the panel.
- Clicking an entity (panel or popover) scrolls the diff to the lines via
pierre's [data-selected-line]; centers only when off-screen so manual
drag-selection isn't disturbed.
- Extract shared rows/helpers into semanticDiffShared; share one cached
/api/semantic-diff fetch across header badges.
* feat(review): land on All files by default
Semantic diff stays available via the file-tree nav entry and header badges,
but it's no longer the initial landing view.
* chore(review): drop dead change-symbol entries, log badge fetch failures
- Remove unreachable 'moved'/'renamed' entries from the changeSymbols table
(getChangeSymbol early-returns for those before the lookup).
- Log a console.error once per patch when the file-header badge's semantic
diff fetch fails or returns a non-ok status, so a systemic failure leaves a
trace instead of every badge silently showing nothing.
* feat(review): flatten semantic diff panel into grouped list
- Dissolve the per-file bordered cards into flat sections: the file path is now
a quiet underlined header (single hairline) with entity rows flush beneath,
hierarchy from whitespace + hover tint instead of boxes.
- Split the path into muted directory + emphasized filename for faster scanning.
- Nudge the add/remove glyphs (⊕/⊖) ~15% larger, line-height pinned so rows
don't grow; modified/rename/reorder glyphs unchanged.
2026-06-08 22:23:54 -07:00
|
|
|
|
feat(install): add --minimal binary-only install mode (#989)
* feat(install): add --minimal binary-only install mode
install.sh installs the plannotator binary and then writes a large amount
of extra state: the sem sidecar, the agent-terminal runtime, and per-agent
skills, hooks, slash commands, and config for Claude, Codex, OpenCode,
Gemini, and Kiro. There is no way to get just the binary — even the
--no-extras path still writes ~/.claude skills and OpenCode commands.
Add a --minimal flag (aliased --binary-only) plus a PLANNOTATOR_MINIMAL
env var for `curl | bash` runs. Minimal mode installs only the binary to
~/.local/bin, prints PATH advice, and exits before any sidecar download,
agent integration, skill checkout, config write, cache clear, or cleanup
migration. Precedence: flag > env var > default (off).
The PATH-advice block is extracted into print_path_advice() so both the
minimal early exit and the normal flow reuse it.
Closes #977
* feat(install): mirror minimal mode to ps1/cmd, add --no-minimal, docs
Extend the binary-only install mode to full cross-installer parity and
address the Copilot review on #989.
install.sh:
- Add --no-minimal (MINIMAL_FLAG=0) so a CLI flag can override
PLANNOTATOR_MINIMAL=1 in both directions; the -1/0/1 comment is now
accurate. --minimal/--no-minimal are mutually exclusive.
- Document the --binary-only alias and soften the absolute "nothing
written outside ..." wording to "no persistent state" (minimal mode
still uses a temp download file and may read the config dir).
install.ps1 / install.cmd:
- Add -Minimal (alias BinaryOnly)/-NoMinimal and --minimal/--binary-only/
--no-minimal with PLANNOTATOR_MINIMAL resolution, mirroring install.sh.
- Extract PATH advice into Show-PathAdvice / :PrintPathAdvice and reuse it
in both the minimal early exit and the normal flow.
- Early-exit after the binary is placed, before the sidecar/agent/skill/
config work.
Tests: add minimal-mode assertions to the install.ps1 and install.cmd
describe blocks plus a shared-behavior test asserting all three installers
support it; extend the sh tests for --no-minimal.
Docs: document --minimal / PLANNOTATOR_MINIMAL in the installation guide
(noting minimal mode needs no git) and add PLANNOTATOR_MINIMAL (and backfill
PLANNOTATOR_SKIP_SEM_INSTALL) to the env-var registries.
* docs(install): correct minimal-mode PATH wording (ps1 persists PATH)
The PowerShell installer's minimal path calls Show-PathAdvice, which
persistently writes the user PATH — so "no persistent state is written
outside $installDir" overpromised. Reword the install.ps1 comment and the
installation docs to describe what minimal mode skips (sidecar, agent
runtime, per-agent integrations) and note the binary + PATH entry are still
added on Windows. Addresses the second Copilot review on #989.
* fix(install.cmd): use delayed expansion for PLANNOTATOR_MINIMAL checks
The three new env-var checks used immediate %VAR% expansion; under
setlocal enabledelayedexpansion a poisoned value re-exposes cmd
metacharacters at parse time (command injection). Switch to the !VAR!
idiom the script already uses for every other untrusted env var (e.g.
the PLANNOTATOR_VERIFY_ATTESTATION block).
---------
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
2026-07-07 00:43:42 +02:00
|
|
|
call :PrintPathAdvice
|
2025-12-28 14:44:54 -08:00
|
|
|
|
2026-03-05 19:17:47 -08:00
|
|
|
REM Validate plugin hooks.json if plugin is already installed
|
|
|
|
|
if defined CLAUDE_CONFIG_DIR (
|
|
|
|
|
set "PLUGIN_HOOKS=%CLAUDE_CONFIG_DIR%\plugins\marketplaces\plannotator\apps\hook\hooks\hooks.json"
|
|
|
|
|
) else (
|
|
|
|
|
set "PLUGIN_HOOKS=%USERPROFILE%\.claude\plugins\marketplaces\plannotator\apps\hook\hooks\hooks.json"
|
|
|
|
|
)
|
|
|
|
|
if exist "!PLUGIN_HOOKS!" (
|
fix: Support Windows markdown paths in CLI annotate flow (#267)
* fix(annotate): support Windows markdown paths in CLI annotate flow
* fix tmp path
* fix resolve-file.ts
* Update command to use EXE_PATH variable
* Update command path for plugin hooks in install.ps1
* test: add core test suite for path resolution, storage, remote detection, and install scripts
- resolve-file: absolute paths, relative paths, case-insensitive search, ignored dirs, extension filtering, ambiguity, Windows separators
- storage: slug generation, tilde expansion, version history, deduplication
- remote: env var detection (PLANNOTATOR_REMOTE, SSH_TTY), port config and validation
- image: tmpdir usage, extension validation
- install scripts: JSON structure validation, checksum verification, arch detection, full exe path in hooks
79 tests, 35ms
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* ci: add test workflow and gate release builds on tests
- New test.yml: runs `bun test` on PRs and pushes to main
- release.yml: tests must pass before build job runs
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: resolve pre-existing test failures for CI compatibility
- project.test.ts: make repo name assertion portable (works in CI where
checkout dir differs from local dev)
- vscode mock: add missing APIs needed by editor-annotations.ts
(comments, languages, Range, CodeActionKind, decorations)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* test: remove Viewer.test.tsx and happy-dom dependency
Tests didn't exercise any application code — they manually constructed
DOM elements inline and verified DOM API behavior, not Viewer.tsx logic.
The mock highlighter didn't simulate real hljs, and one test could never
fail due to its try/catch structure.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: use targeted markdown glob and restore clean lockfile
- Replace **/* glob with **/*.[mM][dD]{,[xX]} to only scan markdown
files during case-insensitive search (avoids iterating every file)
- Restore package.json key ordering from main, only removing happy-dom
- Regenerate bun.lock from main's base to eliminate version drift
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* test: drop redundant test and fix weak assertion
- Remove redundant PLANNOTATOR_REMOTE=TRUE test (already covered by true)
- Fix UPLOAD_DIR assertion that would pass even with hardcoded /tmp
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-11 09:47:07 +09:00
|
|
|
REM Use full path so the hook works without PATH being set in the shell
|
|
|
|
|
set "EXE_PATH=!INSTALL_PATH:\=/!"
|
2026-03-05 19:17:47 -08:00
|
|
|
(
|
|
|
|
|
echo {
|
|
|
|
|
echo "hooks": {
|
2026-05-11 08:14:13 -04:00
|
|
|
echo "PreToolUse": [
|
|
|
|
|
echo {
|
|
|
|
|
echo "matcher": "EnterPlanMode",
|
|
|
|
|
echo "hooks": [
|
|
|
|
|
echo {
|
|
|
|
|
echo "type": "command",
|
2026-07-10 06:50:40 -07:00
|
|
|
echo "command": "\"!EXE_PATH!\" improve-context",
|
2026-05-11 08:14:13 -04:00
|
|
|
echo "timeout": 5
|
|
|
|
|
echo }
|
|
|
|
|
echo ]
|
|
|
|
|
echo }
|
|
|
|
|
echo ],
|
2026-03-05 19:17:47 -08:00
|
|
|
echo "PermissionRequest": [
|
|
|
|
|
echo {
|
|
|
|
|
echo "matcher": "ExitPlanMode",
|
|
|
|
|
echo "hooks": [
|
|
|
|
|
echo {
|
|
|
|
|
echo "type": "command",
|
2026-07-10 06:50:40 -07:00
|
|
|
echo "command": "\"!EXE_PATH!\"",
|
2026-03-05 19:17:47 -08:00
|
|
|
echo "timeout": 345600
|
|
|
|
|
echo }
|
|
|
|
|
echo ]
|
|
|
|
|
echo }
|
|
|
|
|
echo ]
|
|
|
|
|
echo }
|
|
|
|
|
echo }
|
|
|
|
|
) > "!PLUGIN_HOOKS!"
|
|
|
|
|
echo Updated plugin hooks at !PLUGIN_HOOKS!
|
|
|
|
|
)
|
|
|
|
|
|
2026-05-02 23:21:42 +03:00
|
|
|
REM Codex hooks on Windows are still experimental upstream. Do not mutate
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM the Codex home automatically from the cmd installer until that path
|
2026-05-02 23:21:42 +03:00
|
|
|
REM is verified end-to-end.
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM Codex stores config and state under CODEX_HOME when set, falling back to
|
|
|
|
|
REM %%USERPROFILE%%\.codex (developers.openai.com/codex/config-advanced). (#852)
|
|
|
|
|
set "CODEX_DIR=%USERPROFILE%\.codex"
|
|
|
|
|
if defined CODEX_HOME set "CODEX_DIR=%CODEX_HOME%"
|
2026-05-05 12:18:18 -07:00
|
|
|
set "CODEX_AVAILABLE=0"
|
2026-05-02 23:21:42 +03:00
|
|
|
where codex >nul 2>&1
|
2026-05-05 12:18:18 -07:00
|
|
|
if !ERRORLEVEL! equ 0 set "CODEX_AVAILABLE=1"
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if exist "!CODEX_DIR!" (
|
|
|
|
|
for /f "delims=" %%C in ('dir /b /a "!CODEX_DIR!" 2^>nul') do (
|
2026-05-05 12:18:18 -07:00
|
|
|
if /i not "%%C"=="skills" if /i not "%%C"==".DS_Store" set "CODEX_AVAILABLE=1"
|
|
|
|
|
)
|
|
|
|
|
)
|
Add Kiro CLI integration (skills + custom agent, cross-platform installers) (#837)
Universal, auto-detected Kiro CLI support — no flag, no separate installer.
When ~/.kiro exists (or kiro-cli is on PATH), the installer copies Plannotator
skills and a custom agent into ~/.kiro, the same convention used for Codex and
Gemini.
- packages/shared: add the kiro-cli agent origin (badge, prompt runtime,
PLAN_TOOL_NAMES). Origin is cosmetic for Kiro (no dedicated AI provider).
- apps/kiro-cli: 3 origin-baked skills (review/annotate/archive) + an example
custom agent that wires every skill via skill:// resources and a
plannotator-scoped shell tool. setup-goal + visual-explainer install from
apps/skills (no content duplication).
- scripts/install.sh: auto-detect ~/.kiro, sparse-checkout apps/kiro-cli,
install 3 kiro + 2 shared skills + the agent (never clobbering an existing
one); covered by scripts/install.test.ts.
- scripts/install.ps1 + install.cmd: Windows parity mirroring the Codex
pattern. Statically verified only; not yet runtime-tested on Windows.
- docs: installation + Kiro guides, AGENTS.md, env-var reference updated.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-02 14:04:18 -04:00
|
|
|
REM Kiro is auto-detected like Codex/Gemini: PATH executable or an existing %USERPROFILE%\.kiro.
|
|
|
|
|
set "KIRO_AVAILABLE=0"
|
|
|
|
|
where kiro-cli >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 set "KIRO_AVAILABLE=1"
|
|
|
|
|
if exist "%USERPROFILE%\.kiro" set "KIRO_AVAILABLE=1"
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM HONEST three-state reporting (#1178): detected-but-skipped is its own
|
|
|
|
|
REM state, never conflated with "not detected". A Codex opt-out leaves the
|
|
|
|
|
REM Codex home entirely untouched (no writes, no cleanup, no removal).
|
|
|
|
|
if "!CODEX_AVAILABLE!"=="1" if "!SKIP_CODEX!"=="1" (
|
|
|
|
|
echo.
|
|
|
|
|
echo Codex: detected, skipped ^(!SKIP_CODEX_SOURCE!^).
|
|
|
|
|
echo The Windows installer only prints manual Codex setup instructions; they
|
|
|
|
|
echo were suppressed.
|
|
|
|
|
REM M4: the existing-integration note only fires when hooks.json actually
|
|
|
|
|
REM references plannotator - mere existence proves nothing, since the
|
|
|
|
|
REM file may hold only the user's own hooks.
|
|
|
|
|
if exist "!CODEX_DIR!\hooks.json" (
|
|
|
|
|
findstr /c:"plannotator" "!CODEX_DIR!\hooks.json" >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 echo Your existing Codex Stop hook at !CODEX_DIR!\hooks.json is unaffected.
|
|
|
|
|
)
|
|
|
|
|
echo Note: the shared agent skills in %USERPROFILE%\.agents\skills serve multiple
|
|
|
|
|
echo agents ^(Codex among them^) and are still installed.
|
|
|
|
|
)
|
|
|
|
|
if "!CODEX_AVAILABLE!"=="1" if "!SKIP_CODEX!"=="0" (
|
2026-05-02 23:21:42 +03:00
|
|
|
echo.
|
|
|
|
|
echo Codex detected.
|
|
|
|
|
echo Codex plan review hooks are experimental on Windows. To try them manually:
|
|
|
|
|
echo.
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
echo 1. Add this to !CODEX_DIR!\config.toml:
|
2026-05-02 23:21:42 +03:00
|
|
|
echo.
|
|
|
|
|
echo [features]
|
2026-05-12 01:02:19 -03:00
|
|
|
echo hooks = true
|
2026-05-02 23:21:42 +03:00
|
|
|
echo.
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
echo 2. Add a Stop hook in !CODEX_DIR!\hooks.json that runs:
|
2026-05-02 23:21:42 +03:00
|
|
|
echo.
|
|
|
|
|
echo !INSTALL_PATH!
|
|
|
|
|
echo.
|
|
|
|
|
)
|
|
|
|
|
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM Clear any cached OpenCode plugin to force fresh download on next run.
|
|
|
|
|
REM An OpenCode opt-out (#1178) leaves OpenCode's own cache directory alone;
|
|
|
|
|
REM the Bun package cache is a shared cache, not OpenCode's home, and is
|
|
|
|
|
REM always cleared.
|
|
|
|
|
if "!SKIP_OPENCODE!"=="0" (
|
|
|
|
|
if exist "%USERPROFILE%\.cache\opencode\node_modules\@plannotator" rmdir /s /q "%USERPROFILE%\.cache\opencode\node_modules\@plannotator" >nul 2>&1
|
|
|
|
|
if exist "%USERPROFILE%\.cache\opencode\packages\@plannotator" rmdir /s /q "%USERPROFILE%\.cache\opencode\packages\@plannotator" >nul 2>&1
|
|
|
|
|
)
|
2026-04-09 07:23:42 -07:00
|
|
|
if exist "%USERPROFILE%\.bun\install\cache\@plannotator" rmdir /s /q "%USERPROFILE%\.bun\install\cache\@plannotator" >nul 2>&1
|
|
|
|
|
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM ----------------------------------------------------------------------
|
|
|
|
|
REM Skills + command stubs install (requires git)
|
|
|
|
|
REM
|
|
|
|
|
REM Claude Code commands are deprecated in favor of skills. Core skills
|
|
|
|
|
REM installed to %%USERPROFILE%%\.claude\skills are user-invocable by directory
|
|
|
|
|
REM name (/plannotator-review etc.), so no command files are written anymore.
|
|
|
|
|
REM
|
|
|
|
|
REM Install matrix (all copies verbatim, copy-if-present so older-tag pinned
|
|
|
|
|
REM installs never fail when a source dir is absent):
|
|
|
|
|
REM %%USERPROFILE%%\.claude\skills <- apps\skills\core\* (all 4)
|
|
|
|
|
REM %%USERPROFILE%%\.agents\skills <- apps\skills\core\* (all 4)
|
|
|
|
|
REM %%USERPROFILE%%\.kiro\skills <- apps\kiro-cli\skills\* (3) + 2 extras (when kiro detected)
|
|
|
|
|
REM %%USERPROFILE%%\.config\opencode\commands <- apps\opencode-plugin\commands\*.md (always)
|
|
|
|
|
REM %%USERPROFILE%%\.gemini\commands <- apps\gemini\commands\*.toml (when ~/.gemini exists)
|
|
|
|
|
REM Nothing goes to the Codex home (CODEX_DIR\skills) anymore.
|
|
|
|
|
REM ----------------------------------------------------------------------
|
|
|
|
|
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Aggressive cleanup on upgrade - echo each removal, ignore missing.
|
|
|
|
|
REM NOTE: legacy Claude command cleanup happens AFTER the skill install below -
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM a command file is only removed once its replacement skill is on disk, so a
|
|
|
|
|
REM failed or skipped skill install never leaves users with neither.
|
2026-02-10 09:13:38 -08:00
|
|
|
if defined CLAUDE_CONFIG_DIR (
|
|
|
|
|
set "CLAUDE_COMMANDS_DIR=%CLAUDE_CONFIG_DIR%\commands"
|
|
|
|
|
) else (
|
|
|
|
|
set "CLAUDE_COMMANDS_DIR=%USERPROFILE%\.claude\commands"
|
|
|
|
|
)
|
2026-01-12 19:36:09 -08:00
|
|
|
|
2026-07-10 06:50:40 -07:00
|
|
|
REM NOTE: Codex stale-skill cleanup happens AFTER the skill install below -
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM the core skills are only removed from the Codex home once their
|
|
|
|
|
REM replacement exists in %%USERPROFILE%%\.agents\skills.
|
|
|
|
|
set "STALE_CODEX_SKILLS_DIR=!CODEX_DIR!\skills"
|
|
|
|
|
|
|
|
|
|
REM Old installers (pre core/extra split) ran a wholesale skills copy against
|
|
|
|
|
REM a new-layout tag and could leave junk core/extra directory copies in the
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Claude skills scope. Never valid skill names - always safe to remove.
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if defined CLAUDE_CONFIG_DIR (
|
|
|
|
|
set "CLAUDE_SKILLS_SCOPE=%CLAUDE_CONFIG_DIR%\skills"
|
|
|
|
|
) else (
|
|
|
|
|
set "CLAUDE_SKILLS_SCOPE=%USERPROFILE%\.claude\skills"
|
|
|
|
|
)
|
|
|
|
|
for %%J in (core extra) do (
|
|
|
|
|
if exist "!CLAUDE_SKILLS_SCOPE!\%%J" (
|
|
|
|
|
rmdir /s /q "!CLAUDE_SKILLS_SCOPE!\%%J" >nul 2>&1
|
|
|
|
|
echo Removed stale layout directory !CLAUDE_SKILLS_SCOPE!\%%J ^(left by an older installer^)
|
|
|
|
|
)
|
|
|
|
|
)
|
2026-01-12 19:36:09 -08:00
|
|
|
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM Extras are no longer managed in the Claude / shared-agent scopes. Remove
|
2026-07-10 06:50:40 -07:00
|
|
|
REM previously default-installed copies ONCE per machine - recorded in the
|
|
|
|
|
REM migrations ledger under the Plannotator data dir - because copies the user
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM reinstalls via `npx skills add` are byte-identical to ours and can only be
|
|
|
|
|
REM told apart by remembering that this cleanup already ran.
|
|
|
|
|
if defined CLAUDE_CONFIG_DIR (
|
|
|
|
|
set "CLAUDE_SKILLS_DIR=%CLAUDE_CONFIG_DIR%\skills"
|
|
|
|
|
) else (
|
|
|
|
|
set "CLAUDE_SKILLS_DIR=%USERPROFILE%\.claude\skills"
|
|
|
|
|
)
|
|
|
|
|
set "AGENTS_SKILLS_DIR=%USERPROFILE%\.agents\skills"
|
|
|
|
|
set "MIGRATIONS_DIR=!_CONFIG_DIR!\migrations"
|
|
|
|
|
set "EXTRAS_MIGRATION=!MIGRATIONS_DIR!\2026-06-extras-default-install-removed"
|
|
|
|
|
if not exist "!EXTRAS_MIGRATION!" (
|
|
|
|
|
for %%S in (plannotator-compound plannotator-setup-goal plannotator-visual-explainer) do (
|
|
|
|
|
if exist "!CLAUDE_SKILLS_DIR!\%%S" (
|
|
|
|
|
rmdir /s /q "!CLAUDE_SKILLS_DIR!\%%S" >nul 2>&1
|
|
|
|
|
echo Removed extra Plannotator skill from !CLAUDE_SKILLS_DIR!\%%S ^(reinstall via npx skills add^)
|
|
|
|
|
)
|
|
|
|
|
if exist "!AGENTS_SKILLS_DIR!\%%S" (
|
|
|
|
|
rmdir /s /q "!AGENTS_SKILLS_DIR!\%%S" >nul 2>&1
|
|
|
|
|
echo Removed extra Plannotator skill from !AGENTS_SKILLS_DIR!\%%S ^(reinstall via npx skills add^)
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
if not exist "!MIGRATIONS_DIR!" mkdir "!MIGRATIONS_DIR!" >nul 2>&1
|
|
|
|
|
type nul > "!EXTRAS_MIGRATION!"
|
|
|
|
|
)
|
2026-01-12 19:36:09 -08:00
|
|
|
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM --- Guided install (interactive consoles only) ---
|
|
|
|
|
REM Mirrors install.sh: two questions (extras? model-invocable skills?),
|
|
|
|
|
REM answers persisted to install-prefs in the Plannotator data dir and reused
|
|
|
|
|
REM silently on re-runs. --reconfigure re-opens the wizard; --non-interactive
|
|
|
|
|
REM forces silence. `set /p` returns empty at EOF, so redirected/CI runs fall
|
|
|
|
|
REM through to the defaults without hanging. Flags win over everything.
|
2026-07-10 06:50:40 -07:00
|
|
|
REM No checkbox UI in batch - the skill picker uses numbered toggles instead.
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
set "PREFS_FILE=!_CONFIG_DIR!\install-prefs"
|
|
|
|
|
set "SAVED_EXTRAS="
|
|
|
|
|
set "SAVED_INVOCABLE="
|
|
|
|
|
if exist "!PREFS_FILE!" (
|
|
|
|
|
for /f "usebackq tokens=1,* delims==" %%A in ("!PREFS_FILE!") do (
|
|
|
|
|
if /i "%%A"=="extras" set "SAVED_EXTRAS=%%B"
|
|
|
|
|
if /i "%%A"=="model_invocable" set "SAVED_INVOCABLE=%%B"
|
|
|
|
|
)
|
|
|
|
|
)
|
2026-03-05 02:37:58 +08:00
|
|
|
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Extras already on disk? Then the extras question is moot - they still
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM count toward the picker list, and we never launch the npx flow over them.
|
|
|
|
|
set "EXTRAS_PRESENT=0"
|
|
|
|
|
for %%S in (plannotator-compound plannotator-setup-goal plannotator-visual-explainer) do (
|
|
|
|
|
if exist "!CLAUDE_SKILLS_DIR!\%%S" set "EXTRAS_PRESENT=1"
|
|
|
|
|
if exist "!AGENTS_SKILLS_DIR!\%%S" set "EXTRAS_PRESENT=1"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
REM A wizard needs a real console. `timeout` exits non-zero when stdin is
|
|
|
|
|
REM redirected ("Input redirection is not supported"), making it a reliable
|
2026-07-10 06:50:40 -07:00
|
|
|
REM console probe - CI and redirected runs never see the wizard and never
|
Plan-look chooser + 0.20.0 release dialog (with GitLab / sem / install fixes) (#879)
* feat(plan): default to the grid look + look-and-feel image chooser
- Flip gridEnabled default back to true (classic grid / floating-card look),
reverting #863's flat-by-default so existing users without an explicit
choice return to the grid view they're used to.
- Rewrite the look-and-feel announcement into a two-image chooser: Grid
(classic, now the default) vs Clean (the new flat look), each a clickable
screenshot that hover-zooms to preview — mirroring the code-review
DiffTypeSetupDialog pattern.
- Bump the announcement version (1 -> 2) so existing users are re-offered the
choice once.
- Add look-grid.png / look-flat.png preview assets (resized app screenshots).
* fix(review): restore GitLab /diffs fallback for MR review
#871's pr-gitlab refactor moved to the raw_diffs endpoint and deleted the
paginated /diffs path, hard-breaking MR review on self-hosted GitLab too old to
expose raw_diffs (opaque "Failed to fetch MR diff") and silently rendering zero
files when raw_diffs returns empty for oversized MRs.
Keep raw_diffs as the primary path (it preserves binary markers + collapsed
content), but fall back to the restored paginated /diffs + reconstructPatch when
raw_diffs fails or is empty, and throw a clear "diff is empty / too large" error
if both come back empty. Restores parsePaginatedArray / reconstructPatch and
adds tests for the fallback paths.
* fix(install): bound the optional sem sidecar download
The semantic-diff 'sem' download (#871) ran curl / Invoke-WebRequest with no
timeout. The sidecar installs after plannotator itself, so a slow or hung fetch
could wedge an otherwise-complete install. Add --connect-timeout 10
--max-time 120/60 (sh, cmd) and -TimeoutSec 120/60 (ps1) so it times out and
skips gracefully, and document the PLANNOTATOR_SKIP_SEM_INSTALL opt-out in the
installer help.
* chore(install): remove the Glimpse install option from the installers
The installers offered to `npm install -g glimpseui` (a wizard prompt +
--glimpse/--no-glimpse flags + saved pref). Drop all of it across install.sh,
install.ps1, and install.cmd: flags, usage text, the wizard question, the
glimpse_present detection, the saved-pref read/write, the persistence clauses,
and the install block. The guided wizard is now two questions (extras,
model-invocable).
Runtime Glimpse support is unchanged: the app still opens in the native window
if glimpseui is on PATH (packages/server/browser.ts), still gated by
PLANNOTATOR_GLIMPSE. Updated install.test.ts (asserts the installers are
glimpse-free) and the installation docs.
* feat(plan): 0.20.0 release announcement dialog
Turn the first-run look chooser into a two-page 0.20.0 announcement.
- Page 1: header with a "Full release notes" link, a four-up feature
grid (fresh look, semantic review, multi-repo review, leaner install),
and the grid/clean plan-look chooser.
- Page 2: "Workspaces are coming" teaser with the waitlist image + link.
- Footer actions grouped bottom-right on both pages (shimmering
"Workspaces are coming" teaser via TextShimmer + the primary action)
so focus stays in one corner across the page turn.
- Reshoot the grid/clean chooser screenshots on a clean prose plan and
add the workspaces teaser image.
* feat(plan): add full-page HTML feature card, lead with leaner install
Add a fifth what's-new card for --render-html (annotate HTML reports and
explainers rendered full-screen) and move Leaner install to the front of
the grid.
2026-06-09 09:45:20 -07:00
|
|
|
REM trigger the wizard-only installs (npx extras). The set /p
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM EOF-fallthrough remains as a second line of defense.
|
|
|
|
|
set "CAN_PROMPT=0"
|
|
|
|
|
timeout /t 0 >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 set "CAN_PROMPT=1"
|
|
|
|
|
if "!NON_INTERACTIVE!"=="1" set "CAN_PROMPT=0"
|
|
|
|
|
set "RUN_WIZARD=0"
|
|
|
|
|
if "!CAN_PROMPT!"=="1" (
|
|
|
|
|
if "!RECONFIGURE!"=="1" set "RUN_WIZARD=1"
|
|
|
|
|
if not exist "!PREFS_FILE!" set "RUN_WIZARD=1"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
set "EXTRAS_CHOICE="
|
|
|
|
|
set "INVOCABLE_CHOICE="
|
|
|
|
|
if "!RUN_WIZARD!"=="1" call :guided_wizard
|
|
|
|
|
|
|
|
|
|
REM Flags override the wizard and saved answers; otherwise saved, then defaults.
|
|
|
|
|
if defined EXTRAS_FLAG set "EXTRAS_CHOICE=!EXTRAS_FLAG!"
|
|
|
|
|
if defined MODEL_INVOCABLE_FLAG set "INVOCABLE_CHOICE=!MODEL_INVOCABLE_FLAG!"
|
|
|
|
|
if not defined EXTRAS_CHOICE (
|
|
|
|
|
if defined SAVED_EXTRAS (set "EXTRAS_CHOICE=!SAVED_EXTRAS!") else (set "EXTRAS_CHOICE=no")
|
|
|
|
|
)
|
|
|
|
|
if not defined INVOCABLE_CHOICE (
|
|
|
|
|
if defined SAVED_INVOCABLE (set "INVOCABLE_CHOICE=!SAVED_INVOCABLE!") else (set "INVOCABLE_CHOICE=none")
|
|
|
|
|
)
|
|
|
|
|
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Persist only when the wizard ran or a flag set something - silent re-runs
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM must not clobber saved answers with defaults.
|
|
|
|
|
set "DO_PERSIST=0"
|
|
|
|
|
if "!RUN_WIZARD!"=="1" set "DO_PERSIST=1"
|
|
|
|
|
if defined EXTRAS_FLAG set "DO_PERSIST=1"
|
|
|
|
|
if defined MODEL_INVOCABLE_FLAG set "DO_PERSIST=1"
|
|
|
|
|
if "!DO_PERSIST!"=="1" (
|
|
|
|
|
if not exist "!_CONFIG_DIR!" mkdir "!_CONFIG_DIR!" >nul 2>&1
|
|
|
|
|
> "!PREFS_FILE!" (
|
|
|
|
|
echo extras=!EXTRAS_CHOICE!
|
|
|
|
|
echo model_invocable=!INVOCABLE_CHOICE!
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
REM Extras install is delegated to the skills CLI (its UI picks the agents).
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Interactive wizard runs only - silent runs and CI get the printed command.
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
REM Never runs when the extras already exist. The extras ARE skills, so
|
|
|
|
|
REM --skip-skills suppresses them too - a saved extras=yes preference must not
|
|
|
|
|
REM smuggle a skill install past the opt-out.
|
|
|
|
|
if "!SKIP_SKILLS!"=="0" if "!EXTRAS_CHOICE!"=="yes" if "!EXTRAS_PRESENT!"=="0" (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
set "NPX_OK=0"
|
|
|
|
|
where npx >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 if "!RUN_WIZARD!"=="1" set "NPX_OK=1"
|
|
|
|
|
if "!NPX_OK!"=="1" (
|
|
|
|
|
echo Launching the skills CLI for the extras ^(pick your agents in its UI^)...
|
2026-07-20 21:05:10 +02:00
|
|
|
call npx skills add backnotprop/plannotator/apps/skills/extra --global
|
|
|
|
|
if not !ERRORLEVEL! equ 0 echo skills CLI did not complete - install later with: npx skills add backnotprop/plannotator/apps/skills/extra --global
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
) else (
|
2026-07-20 21:05:10 +02:00
|
|
|
echo Install the extras with: npx skills add backnotprop/plannotator/apps/skills/extra --global
|
2026-05-05 12:18:18 -07:00
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM File-copy installs require git (sparse checkout). Hard requirement: without
|
|
|
|
|
REM git we cannot install the /plannotator-* skills, so fail loudly instead of
|
|
|
|
|
REM leaving a partial install. Hook/config writing above has already run; the
|
|
|
|
|
REM Pi update and Gemini config below are skipped on failure and complete when
|
|
|
|
|
REM the user re-runs the installer.
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
REM
|
|
|
|
|
REM Skills/commands opt-out (--skip-skills / PLANNOTATOR_SKIP_SKILLS_INSTALL /
|
|
|
|
|
REM skipInstall.skills). HONEST reporting like the per-agent family: the skipped
|
|
|
|
|
REM state is announced, and skip means do-not-write - nothing already on disk in
|
|
|
|
|
REM any skill or command scope is fetched, replaced, or removed on this run.
|
|
|
|
|
REM Nothing is fetched, so git also stops being a requirement here.
|
|
|
|
|
if "!SKIP_SKILLS!"=="1" (
|
|
|
|
|
echo.
|
|
|
|
|
echo Skills: skipped ^(!SKIP_SKILLS_SOURCE!^).
|
|
|
|
|
echo No skills or slash commands were fetched, and none already installed
|
|
|
|
|
echo were changed or removed. The /plannotator-* commands are NOT installed
|
|
|
|
|
echo by this run - re-run without the opt-out to install them.
|
|
|
|
|
) else (
|
|
|
|
|
where git >nul 2>&1
|
|
|
|
|
if not !ERRORLEVEL! equ 0 (
|
|
|
|
|
echo Error: git is required to install Plannotator's skills and slash commands. 1>&2
|
|
|
|
|
echo Install git, then run this installer again. 1>&2
|
|
|
|
|
echo To install without them, re-run with --skip-skills. 1>&2
|
|
|
|
|
exit /b 1
|
|
|
|
|
)
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
)
|
|
|
|
|
set "CHECKOUT_FAILED=0"
|
|
|
|
|
set "KIRO_SKILLS_DIR=%USERPROFILE%\.kiro\skills"
|
|
|
|
|
set "KIRO_AGENTS_DIR=%USERPROFILE%\.kiro\agents"
|
|
|
|
|
set "OPENCODE_COMMANDS_DIR=%USERPROFILE%\.config\opencode\commands"
|
|
|
|
|
set "GEMINI_COMMANDS_DIR=%USERPROFILE%\.gemini\commands"
|
|
|
|
|
set "SKILLS_TMP=%TEMP%\plannotator-skills-%RANDOM%"
|
|
|
|
|
mkdir "!SKILLS_TMP!" >nul 2>&1
|
|
|
|
|
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
REM Opt-out: jump past the clone so no network call is made and
|
|
|
|
|
REM CHECKOUT_FAILED stays 0 - an opt-out is not a fetch failure and must not
|
|
|
|
|
REM trip the guard below. Reported above, next to the git check.
|
|
|
|
|
if "!SKIP_SKILLS!"=="1" goto skills_checkout_done
|
|
|
|
|
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
git clone --depth 1 --filter=blob:none --sparse "https://github.com/!REPO!.git" --branch "!TAG!" "!SKILLS_TMP!\repo" >nul 2>&1
|
2026-03-25 00:17:19 -07:00
|
|
|
if !ERRORLEVEL! equ 0 (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
pushd "!SKILLS_TMP!\repo"
|
|
|
|
|
git sparse-checkout set apps/skills apps/kiro-cli apps/opencode-plugin/commands apps/gemini/commands >nul 2>&1
|
|
|
|
|
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Claude Code reads apps\skills\claude\* (injection `!`plannotator ... $ARGUMENTS``
|
2026-06-08 10:28:18 -07:00
|
|
|
REM + allowed-tools, so /plannotator-* run with no permission prompt); Codex
|
2026-07-10 06:50:40 -07:00
|
|
|
REM reads apps\skills\core\* (prose). The `!`...`` injection is Claude-Code-only,
|
2026-06-08 10:28:18 -07:00
|
|
|
REM so the two are sourced separately. Replace rather than merge on each run.
|
|
|
|
|
if exist "apps\skills\claude" (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if not exist "!CLAUDE_SKILLS_DIR!" mkdir "!CLAUDE_SKILLS_DIR!"
|
chore: remove the redundant /plannotator-status and /plannotator-archive commands (#873)
Two agent command-surface cleanups. Both remove only the command entry points; all underlying infrastructure stays.
1. /plannotator-status (Pi): removed — it echoed phase/plan-file/progress on
demand, but that state is already shown ambiently (status bar + live
checklist widget). The phase/checklist state machine is untouched.
2. /plannotator-archive (all agents): removed the command/skill entry points
across every surface — Claude/Codex/Kiro skills, Pi, OpenCode (handler +
dispatch + cli-bridge + embedded + stub), Droid, the Kiro agent prompt, all
three installers, docs, marketing, and the CI deprecated-command guard. The
installers also gained a stale-skill cleanup so upgraders drop a previously
installed plannotator-archive skill.
Kept (infrastructure) — archive browsing stays available in-review via the
sidebar: the `plannotator archive` CLI subcommand (apps/hook/server), the
mode:"archive" server path + /api/archive endpoints, ArchiveBrowser/useArchive,
the sidebar Archive tab, sessions.ts "archive" mode, and ~/.plannotator/plans
storage.
Verified: bun test scripts/install.test.ts → 72 pass; pi-extension typecheck +
build:opencode pass; repo-wide residual scan clean; KEEP-set integrity
confirmed; one orphaned import (opencode commands.ts) caught in self-review and
removed.
2026-06-08 11:08:11 -07:00
|
|
|
for %%S in (plannotator-review plannotator-annotate plannotator-last) do (
|
2026-06-08 10:28:18 -07:00
|
|
|
if exist "apps\skills\claude\%%S" (
|
|
|
|
|
if exist "!CLAUDE_SKILLS_DIR!\%%S" rmdir /s /q "!CLAUDE_SKILLS_DIR!\%%S" >nul 2>&1
|
|
|
|
|
xcopy /s /i /y /q "apps\skills\claude\%%S" "!CLAUDE_SKILLS_DIR!\%%S\" >nul 2>&1
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
echo Installed Claude Code skills to !CLAUDE_SKILLS_DIR!\
|
|
|
|
|
)
|
|
|
|
|
if exist "apps\skills\core" (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if not exist "!AGENTS_SKILLS_DIR!" mkdir "!AGENTS_SKILLS_DIR!"
|
chore: remove the redundant /plannotator-status and /plannotator-archive commands (#873)
Two agent command-surface cleanups. Both remove only the command entry points; all underlying infrastructure stays.
1. /plannotator-status (Pi): removed — it echoed phase/plan-file/progress on
demand, but that state is already shown ambiently (status bar + live
checklist widget). The phase/checklist state machine is untouched.
2. /plannotator-archive (all agents): removed the command/skill entry points
across every surface — Claude/Codex/Kiro skills, Pi, OpenCode (handler +
dispatch + cli-bridge + embedded + stub), Droid, the Kiro agent prompt, all
three installers, docs, marketing, and the CI deprecated-command guard. The
installers also gained a stale-skill cleanup so upgraders drop a previously
installed plannotator-archive skill.
Kept (infrastructure) — archive browsing stays available in-review via the
sidebar: the `plannotator archive` CLI subcommand (apps/hook/server), the
mode:"archive" server path + /api/archive endpoints, ArchiveBrowser/useArchive,
the sidebar Archive tab, sessions.ts "archive" mode, and ~/.plannotator/plans
storage.
Verified: bun test scripts/install.test.ts → 72 pass; pi-extension typecheck +
build:opencode pass; repo-wide residual scan clean; KEEP-set integrity
confirmed; one orphaned import (opencode commands.ts) caught in self-review and
removed.
2026-06-08 11:08:11 -07:00
|
|
|
for %%S in (plannotator-review plannotator-annotate plannotator-last) do (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if exist "apps\skills\core\%%S" (
|
|
|
|
|
REM Replace rather than merge so files removed upstream don't linger.
|
|
|
|
|
if exist "!AGENTS_SKILLS_DIR!\%%S" rmdir /s /q "!AGENTS_SKILLS_DIR!\%%S" >nul 2>&1
|
|
|
|
|
xcopy /s /i /y /q "apps\skills\core\%%S" "!AGENTS_SKILLS_DIR!\%%S\" >nul 2>&1
|
|
|
|
|
)
|
|
|
|
|
)
|
2026-06-08 10:28:18 -07:00
|
|
|
echo Installed shared agent skills to !AGENTS_SKILLS_DIR!\
|
2026-03-25 00:17:19 -07:00
|
|
|
) else (
|
2026-07-10 06:50:40 -07:00
|
|
|
echo Tag !TAG! predates the core/extra skill layout - skipping core skill install
|
2026-03-25 00:17:19 -07:00
|
|
|
)
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM OpenCode command stubs -> always (plugin intercepts execution),
|
|
|
|
|
REM unless opted out via --skip-opencode (#1178).
|
|
|
|
|
if "!SKIP_OPENCODE!"=="0" if exist "apps\opencode-plugin\commands" (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if not exist "!OPENCODE_COMMANDS_DIR!" mkdir "!OPENCODE_COMMANDS_DIR!"
|
|
|
|
|
xcopy /y /q "apps\opencode-plugin\commands\*.md" "!OPENCODE_COMMANDS_DIR!\" >nul 2>&1
|
|
|
|
|
echo Installed OpenCode commands to !OPENCODE_COMMANDS_DIR!\
|
|
|
|
|
)
|
|
|
|
|
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM Gemini TOML commands -> only when ~/.gemini exists (Gemini's native
|
|
|
|
|
REM format) and not opted out (#1178).
|
|
|
|
|
if exist "%USERPROFILE%\.gemini" if "!SKIP_GEMINI!"=="0" if exist "apps\gemini\commands" (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if not exist "!GEMINI_COMMANDS_DIR!" mkdir "!GEMINI_COMMANDS_DIR!"
|
|
|
|
|
xcopy /y /q "apps\gemini\commands\*.toml" "!GEMINI_COMMANDS_DIR!\" >nul 2>&1
|
|
|
|
|
echo Installed Gemini commands to !GEMINI_COMMANDS_DIR!\
|
|
|
|
|
)
|
|
|
|
|
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM Kiro -> hand-maintained kiro skills (3) + 2 extras, only when detected
|
|
|
|
|
REM and not opted out (#1178: a Kiro opt-out leaves ~/.kiro untouched).
|
|
|
|
|
if "!KIRO_AVAILABLE!"=="1" if "!SKIP_KIRO!"=="0" if exist "apps\kiro-cli\skills" (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if not exist "!KIRO_SKILLS_DIR!" mkdir "!KIRO_SKILLS_DIR!"
|
|
|
|
|
REM Kiro-specific skills with origin baked in come from apps\kiro-cli\skills.
|
chore: remove the redundant /plannotator-status and /plannotator-archive commands (#873)
Two agent command-surface cleanups. Both remove only the command entry points; all underlying infrastructure stays.
1. /plannotator-status (Pi): removed — it echoed phase/plan-file/progress on
demand, but that state is already shown ambiently (status bar + live
checklist widget). The phase/checklist state machine is untouched.
2. /plannotator-archive (all agents): removed the command/skill entry points
across every surface — Claude/Codex/Kiro skills, Pi, OpenCode (handler +
dispatch + cli-bridge + embedded + stub), Droid, the Kiro agent prompt, all
three installers, docs, marketing, and the CI deprecated-command guard. The
installers also gained a stale-skill cleanup so upgraders drop a previously
installed plannotator-archive skill.
Kept (infrastructure) — archive browsing stays available in-review via the
sidebar: the `plannotator archive` CLI subcommand (apps/hook/server), the
mode:"archive" server path + /api/archive endpoints, ArchiveBrowser/useArchive,
the sidebar Archive tab, sessions.ts "archive" mode, and ~/.plannotator/plans
storage.
Verified: bun test scripts/install.test.ts → 72 pass; pi-extension typecheck +
build:opencode pass; repo-wide residual scan clean; KEEP-set integrity
confirmed; one orphaned import (opencode commands.ts) caught in self-review and
removed.
2026-06-08 11:08:11 -07:00
|
|
|
for %%S in (plannotator-review plannotator-annotate) do (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if exist "apps\kiro-cli\skills\%%S" (
|
|
|
|
|
if exist "!KIRO_SKILLS_DIR!\%%S" rmdir /s /q "!KIRO_SKILLS_DIR!\%%S" >nul 2>&1
|
|
|
|
|
xcopy /s /i /y /q "apps\kiro-cli\skills\%%S" "!KIRO_SKILLS_DIR!\%%S\" >nul 2>&1
|
Add Kiro CLI integration (skills + custom agent, cross-platform installers) (#837)
Universal, auto-detected Kiro CLI support — no flag, no separate installer.
When ~/.kiro exists (or kiro-cli is on PATH), the installer copies Plannotator
skills and a custom agent into ~/.kiro, the same convention used for Codex and
Gemini.
- packages/shared: add the kiro-cli agent origin (badge, prompt runtime,
PLAN_TOOL_NAMES). Origin is cosmetic for Kiro (no dedicated AI provider).
- apps/kiro-cli: 3 origin-baked skills (review/annotate/archive) + an example
custom agent that wires every skill via skill:// resources and a
plannotator-scoped shell tool. setup-goal + visual-explainer install from
apps/skills (no content duplication).
- scripts/install.sh: auto-detect ~/.kiro, sparse-checkout apps/kiro-cli,
install 3 kiro + 2 shared skills + the agent (never clobbering an existing
one); covered by scripts/install.test.ts.
- scripts/install.ps1 + install.cmd: Windows parity mirroring the Codex
pattern. Statically verified only; not yet runtime-tested on Windows.
- docs: installation + Kiro guides, AGENTS.md, env-var reference updated.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-02 14:04:18 -04:00
|
|
|
)
|
2026-03-25 00:17:19 -07:00
|
|
|
)
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM The two extras Kiro keeps receiving come from apps\skills\extra.
|
|
|
|
|
if exist "apps\skills\extra\plannotator-setup-goal" (
|
|
|
|
|
if exist "!KIRO_SKILLS_DIR!\plannotator-setup-goal" rmdir /s /q "!KIRO_SKILLS_DIR!\plannotator-setup-goal" >nul 2>&1
|
|
|
|
|
xcopy /s /i /y /q "apps\skills\extra\plannotator-setup-goal" "!KIRO_SKILLS_DIR!\plannotator-setup-goal\" >nul 2>&1
|
|
|
|
|
)
|
|
|
|
|
if exist "apps\skills\extra\plannotator-visual-explainer" (
|
|
|
|
|
if exist "!KIRO_SKILLS_DIR!\plannotator-visual-explainer" rmdir /s /q "!KIRO_SKILLS_DIR!\plannotator-visual-explainer" >nul 2>&1
|
|
|
|
|
xcopy /s /i /y /q "apps\skills\extra\plannotator-visual-explainer" "!KIRO_SKILLS_DIR!\plannotator-visual-explainer\" >nul 2>&1
|
|
|
|
|
)
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Plannotator custom agent - don't clobber a user's existing one.
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if not exist "!KIRO_AGENTS_DIR!\plannotator.json" if exist "apps\kiro-cli\agents\plannotator.json" (
|
|
|
|
|
if not exist "!KIRO_AGENTS_DIR!" mkdir "!KIRO_AGENTS_DIR!"
|
|
|
|
|
copy /y "apps\kiro-cli\agents\plannotator.json" "!KIRO_AGENTS_DIR!\plannotator.json" >nul 2>&1
|
|
|
|
|
)
|
|
|
|
|
echo Installed Kiro skills to !KIRO_SKILLS_DIR!\ and agent to !KIRO_AGENTS_DIR!\plannotator.json
|
2026-03-25 00:17:19 -07:00
|
|
|
)
|
|
|
|
|
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
popd
|
2026-03-25 00:17:19 -07:00
|
|
|
) else (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
set "CHECKOUT_FAILED=1"
|
2026-03-25 00:17:19 -07:00
|
|
|
)
|
|
|
|
|
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
:skills_checkout_done
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
rmdir /s /q "!SKILLS_TMP!" >nul 2>&1
|
|
|
|
|
|
|
|
|
|
if "!CHECKOUT_FAILED!"=="1" (
|
|
|
|
|
echo Error: unable to fetch !REPO! at !TAG! ^(network or git error^). 1>&2
|
2026-07-10 06:50:40 -07:00
|
|
|
echo Something went wrong - run the installer again. 1>&2
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
exit /b 1
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
REM Claude Code commands are deprecated in favor of skills. Remove a legacy
|
2026-07-10 06:50:40 -07:00
|
|
|
REM command file only once its replacement skill is actually on disk - running
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM AFTER the install above guarantees a failed or skipped skill install never
|
|
|
|
|
REM leaves users with neither the command nor the skill.
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
REM A skills opt-out installed no replacement this run, so it removes nothing
|
|
|
|
|
REM either - skip means do-not-write, never remove.
|
chore: remove the redundant /plannotator-status and /plannotator-archive commands (#873)
Two agent command-surface cleanups. Both remove only the command entry points; all underlying infrastructure stays.
1. /plannotator-status (Pi): removed — it echoed phase/plan-file/progress on
demand, but that state is already shown ambiently (status bar + live
checklist widget). The phase/checklist state machine is untouched.
2. /plannotator-archive (all agents): removed the command/skill entry points
across every surface — Claude/Codex/Kiro skills, Pi, OpenCode (handler +
dispatch + cli-bridge + embedded + stub), Droid, the Kiro agent prompt, all
three installers, docs, marketing, and the CI deprecated-command guard. The
installers also gained a stale-skill cleanup so upgraders drop a previously
installed plannotator-archive skill.
Kept (infrastructure) — archive browsing stays available in-review via the
sidebar: the `plannotator archive` CLI subcommand (apps/hook/server), the
mode:"archive" server path + /api/archive endpoints, ArchiveBrowser/useArchive,
the sidebar Archive tab, sessions.ts "archive" mode, and ~/.plannotator/plans
storage.
Verified: bun test scripts/install.test.ts → 72 pass; pi-extension typecheck +
build:opencode pass; repo-wide residual scan clean; KEEP-set integrity
confirmed; one orphaned import (opencode commands.ts) caught in self-review and
removed.
2026-06-08 11:08:11 -07:00
|
|
|
for %%C in (plannotator-review plannotator-annotate plannotator-last) do (
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
if "!SKIP_SKILLS!"=="0" if exist "!CLAUDE_SKILLS_DIR!\%%C" if exist "!CLAUDE_COMMANDS_DIR!\%%C.md" (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
del /q "!CLAUDE_COMMANDS_DIR!\%%C.md" >nul 2>&1
|
|
|
|
|
echo Removed deprecated Claude command !CLAUDE_COMMANDS_DIR!\%%C.md ^(replaced by the %%C skill^)
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
chore: remove the redundant /plannotator-status and /plannotator-archive commands (#873)
Two agent command-surface cleanups. Both remove only the command entry points; all underlying infrastructure stays.
1. /plannotator-status (Pi): removed — it echoed phase/plan-file/progress on
demand, but that state is already shown ambiently (status bar + live
checklist widget). The phase/checklist state machine is untouched.
2. /plannotator-archive (all agents): removed the command/skill entry points
across every surface — Claude/Codex/Kiro skills, Pi, OpenCode (handler +
dispatch + cli-bridge + embedded + stub), Droid, the Kiro agent prompt, all
three installers, docs, marketing, and the CI deprecated-command guard. The
installers also gained a stale-skill cleanup so upgraders drop a previously
installed plannotator-archive skill.
Kept (infrastructure) — archive browsing stays available in-review via the
sidebar: the `plannotator archive` CLI subcommand (apps/hook/server), the
mode:"archive" server path + /api/archive endpoints, ArchiveBrowser/useArchive,
the sidebar Archive tab, sessions.ts "archive" mode, and ~/.plannotator/plans
storage.
Verified: bun test scripts/install.test.ts → 72 pass; pi-extension typecheck +
build:opencode pass; repo-wide residual scan clean; KEEP-set integrity
confirmed; one orphaned import (opencode commands.ts) caught in self-review and
removed.
2026-06-08 11:08:11 -07:00
|
|
|
REM plannotator-archive no longer ships as a skill. Remove any stale installed
|
|
|
|
|
REM copy from every skill scope so upgraders don't keep a dead skill around.
|
|
|
|
|
for %%D in ("!CLAUDE_SKILLS_DIR!" "!AGENTS_SKILLS_DIR!" "!KIRO_SKILLS_DIR!") do (
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM A Kiro opt-out leaves ~/.kiro entirely untouched - including this sweep.
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
REM A skills opt-out leaves every skill scope untouched, sweep included.
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
set "SCOPE_OK=1"
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
if "!SKIP_SKILLS!"=="1" set "SCOPE_OK=0"
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
if /i "%%~D"=="!KIRO_SKILLS_DIR!" if "!SKIP_KIRO!"=="1" set "SCOPE_OK=0"
|
|
|
|
|
if "!SCOPE_OK!"=="1" if exist "%%~D\plannotator-archive" (
|
chore: remove the redundant /plannotator-status and /plannotator-archive commands (#873)
Two agent command-surface cleanups. Both remove only the command entry points; all underlying infrastructure stays.
1. /plannotator-status (Pi): removed — it echoed phase/plan-file/progress on
demand, but that state is already shown ambiently (status bar + live
checklist widget). The phase/checklist state machine is untouched.
2. /plannotator-archive (all agents): removed the command/skill entry points
across every surface — Claude/Codex/Kiro skills, Pi, OpenCode (handler +
dispatch + cli-bridge + embedded + stub), Droid, the Kiro agent prompt, all
three installers, docs, marketing, and the CI deprecated-command guard. The
installers also gained a stale-skill cleanup so upgraders drop a previously
installed plannotator-archive skill.
Kept (infrastructure) — archive browsing stays available in-review via the
sidebar: the `plannotator archive` CLI subcommand (apps/hook/server), the
mode:"archive" server path + /api/archive endpoints, ArchiveBrowser/useArchive,
the sidebar Archive tab, sessions.ts "archive" mode, and ~/.plannotator/plans
storage.
Verified: bun test scripts/install.test.ts → 72 pass; pi-extension typecheck +
build:opencode pass; repo-wide residual scan clean; KEEP-set integrity
confirmed; one orphaned import (opencode commands.ts) caught in self-review and
removed.
2026-06-08 11:08:11 -07:00
|
|
|
rmdir /s /q "%%~D\plannotator-archive" >nul 2>&1
|
|
|
|
|
echo Removed stale plannotator-archive skill from %%~D\plannotator-archive
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
2026-07-10 06:50:40 -07:00
|
|
|
REM The /plannotator-archive OpenCode command was removed too - sweep the stub.
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM An OpenCode opt-out suspends the sweep: skip means do-not-write, never remove.
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
REM A skills opt-out suspends it for the same reason.
|
|
|
|
|
if "!SKIP_OPENCODE!"=="0" if "!SKIP_SKILLS!"=="0" if exist "!OPENCODE_COMMANDS_DIR!\plannotator-archive.md" (
|
2026-06-08 14:51:55 -07:00
|
|
|
del /q "!OPENCODE_COMMANDS_DIR!\plannotator-archive.md" >nul 2>&1
|
|
|
|
|
echo Removed stale plannotator-archive command from !OPENCODE_COMMANDS_DIR!
|
|
|
|
|
)
|
|
|
|
|
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM Codex no longer hosts core skills (they live in %%USERPROFILE%%\.agents\skills).
|
|
|
|
|
REM Core skills are removed only once their replacement exists; the stale
|
|
|
|
|
REM shared-agent extras were never Codex's and are removed unconditionally.
|
|
|
|
|
for %%S in (plannotator-review plannotator-annotate plannotator-last plannotator-compound plannotator-setup-goal) do (
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM A Codex opt-out leaves the Codex home entirely untouched - including
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
REM this stale-skill cleanup. Skip means do-not-write, never remove. A
|
|
|
|
|
REM skills opt-out installed no replacement, so it suspends the sweep too.
|
|
|
|
|
if "!SKIP_CODEX!"=="0" if "!SKIP_SKILLS!"=="0" if exist "!STALE_CODEX_SKILLS_DIR!\%%S" (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
set "OK_REMOVE=1"
|
|
|
|
|
if "%%S"=="plannotator-review" if not exist "!AGENTS_SKILLS_DIR!\%%S" set "OK_REMOVE=0"
|
|
|
|
|
if "%%S"=="plannotator-annotate" if not exist "!AGENTS_SKILLS_DIR!\%%S" set "OK_REMOVE=0"
|
|
|
|
|
if "%%S"=="plannotator-last" if not exist "!AGENTS_SKILLS_DIR!\%%S" set "OK_REMOVE=0"
|
|
|
|
|
if "!OK_REMOVE!"=="1" (
|
|
|
|
|
rmdir /s /q "!STALE_CODEX_SKILLS_DIR!\%%S" >nul 2>&1
|
|
|
|
|
echo Removed Plannotator skill from !STALE_CODEX_SKILLS_DIR!\%%S
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
REM Apply the saved model-invocation choices. Installed skill copies always
|
|
|
|
|
REM arrive locked (disable-model-invocation: true in SKILL.md); for each
|
|
|
|
|
REM chosen skill we unlock the INSTALLED copy by removing that line, and flip
|
|
|
|
|
REM the Codex sidecar's allow_implicit_invocation to match. Re-applied on
|
|
|
|
|
REM every run because installs replace the skill folders wholesale.
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
REM A skills opt-out installed no skill copies this run, so there is nothing to
|
|
|
|
|
REM unlock - and rewriting a PREVIOUS run's SKILL.md would be a write the
|
|
|
|
|
REM opt-out promised not to make.
|
|
|
|
|
if "!SKIP_SKILLS!"=="0" if defined INVOCABLE_CHOICE if not "!INVOCABLE_CHOICE!"=="none" (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
for %%K in ("!INVOCABLE_CHOICE:,=" "!") do (
|
|
|
|
|
for %%D in ("!CLAUDE_SKILLS_DIR!" "!AGENTS_SKILLS_DIR!") do (
|
|
|
|
|
if exist "%%~D\%%~K\SKILL.md" (
|
|
|
|
|
findstr /c:"disable-model-invocation: true" "%%~D\%%~K\SKILL.md" >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 (
|
|
|
|
|
findstr /v /c:"disable-model-invocation: true" "%%~D\%%~K\SKILL.md" > "%%~D\%%~K\SKILL.md.tmp"
|
|
|
|
|
move /y "%%~D\%%~K\SKILL.md.tmp" "%%~D\%%~K\SKILL.md" >nul 2>&1
|
|
|
|
|
echo Enabled model invocation: %%~D\%%~K
|
|
|
|
|
)
|
2026-05-06 15:12:47 -07:00
|
|
|
)
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
if exist "%%~D\%%~K\agents\openai.yaml" (
|
|
|
|
|
findstr /c:"allow_implicit_invocation: false" "%%~D\%%~K\agents\openai.yaml" >nul 2>&1
|
2026-05-06 15:12:47 -07:00
|
|
|
if !ERRORLEVEL! equ 0 (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
powershell -NoProfile -Command "(Get-Content '%%~D\%%~K\agents\openai.yaml' -Raw) -replace 'allow_implicit_invocation: false','allow_implicit_invocation: true' | Set-Content '%%~D\%%~K\agents\openai.yaml' -NoNewline"
|
2026-05-06 15:12:47 -07:00
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
)
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
REM Update Pi extension if pi is installed. Pi keeps its 6 extension commands
|
|
|
|
|
REM and the plannotator_submit_plan tool; it no longer bundles skills, so there
|
|
|
|
|
REM is no settings.json package-skills filter to configure.
|
|
|
|
|
where pi >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 (
|
|
|
|
|
echo Updating Pi extension...
|
|
|
|
|
pi install npm:@plannotator/pi-extension
|
|
|
|
|
if !ERRORLEVEL! equ 0 (
|
2026-05-06 15:12:47 -07:00
|
|
|
echo Pi extension updated.
|
|
|
|
|
) else (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
echo Skipping Pi update ^(pi install failed^)
|
2026-05-06 15:12:47 -07:00
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
feat(gemini): add Gemini CLI plan review integration
* feat(gemini): add Gemini CLI plan review integration
Adds a new `apps/gemini-hook/` adapter that enables Plannotator plan
review for Gemini CLI users via the BeforeTool hook system.
The adapter reads the plan file from disk (Gemini provides a path, not
inline content), delegates to the shared @plannotator/server for the
browser-based review UI, and translates the decision back into Gemini's
hook output format.
Requires an upstream fix (google-gemini/gemini-cli#21802) that makes
`decision = "allow"` user policies work for exit_plan_mode, allowing
hooks to replace the built-in TUI approval dialog.
Includes:
- apps/gemini-hook/server/index.ts — stdin/stdout adapter
- apps/gemini-hook/hooks/ — policy TOML + settings snippet
- scripts/install.sh — Gemini binary download, policy install, settings config
For provenance purposes, this commit was AI assisted.
* refactor(gemini): use single binary with auto-detection instead of separate app
Removes apps/gemini-hook/ — the plannotator binary now auto-detects
Gemini CLI from stdin (plan_path = file on disk) vs Claude Code
(plan = inline content) and branches input parsing + output formatting.
Config fixtures live in apps/gemini/ (policy TOML + settings snippet).
Install script gates on ~/.gemini existing so Claude-only users are
unaffected.
For provenance purposes, this commit was AI assisted.
* test(gemini): add manual sandbox script for Gemini CLI integration
Three modes:
- --simulate: pipes BeforeTool JSON to hook, tests approve/deny output
- (default): runs local patched Gemini build
- --nightly: installs Gemini nightly and runs it
Backs up and restores ~/.gemini config on exit.
For provenance purposes, this commit was AI assisted.
* feat(gemini): add slash commands, marketing tab, and docs for Gemini CLI
- Add /plannotator-review and /plannotator-annotate slash commands (.toml)
- Install Gemini slash commands in all three install scripts (sh, ps1, cmd)
- Add Gemini tab to marketing landing page with icon
- Add Gemini CLI to top-level README install section
- Create apps/gemini/README.md with full setup and usage docs
- Remove stale dev:gemini script and regenerate bun.lock
For provenance purposes, this commit was AI assisted.
* fix(gemini): merge hook into existing settings.json instead of printing instructions
When ~/.gemini/settings.json already exists, use node to JSON-merge
the BeforeTool hook config rather than asking the user to do it manually.
Falls back to instructions only if node is unavailable.
For provenance purposes, this commit was AI assisted.
* fix(gemini): handle plan_filename rename and fix scoping bug
Gemini CLI nightly renamed plan_path to plan_filename in exit_plan_mode.
Accept both field names for forward/backward compatibility. Reconstruct
full plan path from transcript_path + session_id + plans/ + filename.
Also hoist planFilename variable out of try block so it's accessible
in the deny output path (was causing ReferenceError).
For provenance purposes, this commit was AI assisted.
* fix(gemini): dim approve button when annotations exist for Gemini CLI
Gemini's hook runner ignores systemMessage on the allow path, so
approve-with-feedback is silently dropped — same limitation as Claude
Code. Extend the existing UI gate to also apply for gemini-cli origin.
For provenance purposes, this commit was AI assisted.
* fix(gemini): add AGENT_CONFIG entry and fix sandbox simulate mode
Register "gemini-cli" in AGENT_CONFIG so the UI shows "Gemini CLI"
with proper badge styling instead of generic "Coding Agent" fallback.
Update sandbox simulate mode to match production input format:
use plan_filename instead of plan_path, include transcript_path,
and simulate the Gemini directory structure for path reconstruction.
For provenance purposes, this commit was AI assisted.
2026-04-02 15:24:10 -07:00
|
|
|
REM --- Gemini CLI support (only if Gemini is installed) ---
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
REM HONEST three-state reporting (#1178): detected-but-skipped is its own
|
|
|
|
|
REM state. A Gemini opt-out leaves ~/.gemini entirely untouched.
|
|
|
|
|
if exist "%USERPROFILE%\.gemini" if "!SKIP_GEMINI!"=="1" (
|
|
|
|
|
echo.
|
|
|
|
|
echo Gemini: detected, skipped ^(!SKIP_GEMINI_SOURCE!^).
|
|
|
|
|
if exist "%USERPROFILE%\.gemini\settings.json" (
|
|
|
|
|
findstr /c:"plannotator" "%USERPROFILE%\.gemini\settings.json" >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 echo An existing Gemini integration at %USERPROFILE%\.gemini\settings.json was left untouched.
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
if exist "%USERPROFILE%\.gemini" if "!SKIP_GEMINI!"=="0" (
|
feat(gemini): add Gemini CLI plan review integration
* feat(gemini): add Gemini CLI plan review integration
Adds a new `apps/gemini-hook/` adapter that enables Plannotator plan
review for Gemini CLI users via the BeforeTool hook system.
The adapter reads the plan file from disk (Gemini provides a path, not
inline content), delegates to the shared @plannotator/server for the
browser-based review UI, and translates the decision back into Gemini's
hook output format.
Requires an upstream fix (google-gemini/gemini-cli#21802) that makes
`decision = "allow"` user policies work for exit_plan_mode, allowing
hooks to replace the built-in TUI approval dialog.
Includes:
- apps/gemini-hook/server/index.ts — stdin/stdout adapter
- apps/gemini-hook/hooks/ — policy TOML + settings snippet
- scripts/install.sh — Gemini binary download, policy install, settings config
For provenance purposes, this commit was AI assisted.
* refactor(gemini): use single binary with auto-detection instead of separate app
Removes apps/gemini-hook/ — the plannotator binary now auto-detects
Gemini CLI from stdin (plan_path = file on disk) vs Claude Code
(plan = inline content) and branches input parsing + output formatting.
Config fixtures live in apps/gemini/ (policy TOML + settings snippet).
Install script gates on ~/.gemini existing so Claude-only users are
unaffected.
For provenance purposes, this commit was AI assisted.
* test(gemini): add manual sandbox script for Gemini CLI integration
Three modes:
- --simulate: pipes BeforeTool JSON to hook, tests approve/deny output
- (default): runs local patched Gemini build
- --nightly: installs Gemini nightly and runs it
Backs up and restores ~/.gemini config on exit.
For provenance purposes, this commit was AI assisted.
* feat(gemini): add slash commands, marketing tab, and docs for Gemini CLI
- Add /plannotator-review and /plannotator-annotate slash commands (.toml)
- Install Gemini slash commands in all three install scripts (sh, ps1, cmd)
- Add Gemini tab to marketing landing page with icon
- Add Gemini CLI to top-level README install section
- Create apps/gemini/README.md with full setup and usage docs
- Remove stale dev:gemini script and regenerate bun.lock
For provenance purposes, this commit was AI assisted.
* fix(gemini): merge hook into existing settings.json instead of printing instructions
When ~/.gemini/settings.json already exists, use node to JSON-merge
the BeforeTool hook config rather than asking the user to do it manually.
Falls back to instructions only if node is unavailable.
For provenance purposes, this commit was AI assisted.
* fix(gemini): handle plan_filename rename and fix scoping bug
Gemini CLI nightly renamed plan_path to plan_filename in exit_plan_mode.
Accept both field names for forward/backward compatibility. Reconstruct
full plan path from transcript_path + session_id + plans/ + filename.
Also hoist planFilename variable out of try block so it's accessible
in the deny output path (was causing ReferenceError).
For provenance purposes, this commit was AI assisted.
* fix(gemini): dim approve button when annotations exist for Gemini CLI
Gemini's hook runner ignores systemMessage on the allow path, so
approve-with-feedback is silently dropped — same limitation as Claude
Code. Extend the existing UI gate to also apply for gemini-cli origin.
For provenance purposes, this commit was AI assisted.
* fix(gemini): add AGENT_CONFIG entry and fix sandbox simulate mode
Register "gemini-cli" in AGENT_CONFIG so the UI shows "Gemini CLI"
with proper badge styling instead of generic "Coding Agent" fallback.
Update sandbox simulate mode to match production input format:
use plan_filename instead of plan_path, include transcript_path,
and simulate the Gemini directory structure for path reconstruction.
For provenance purposes, this commit was AI assisted.
2026-04-02 15:24:10 -07:00
|
|
|
REM Install policy file
|
|
|
|
|
if not exist "%USERPROFILE%\.gemini\policies" mkdir "%USERPROFILE%\.gemini\policies"
|
|
|
|
|
(
|
|
|
|
|
echo # Plannotator policy for Gemini CLI
|
|
|
|
|
echo # Allows exit_plan_mode without TUI confirmation so the browser UI is the sole gate.
|
|
|
|
|
echo [[rule]]
|
|
|
|
|
echo toolName = "exit_plan_mode"
|
|
|
|
|
echo decision = "allow"
|
|
|
|
|
echo priority = 100
|
|
|
|
|
) > "%USERPROFILE%\.gemini\policies\plannotator.toml"
|
|
|
|
|
echo Installed Gemini policy to %USERPROFILE%\.gemini\policies\plannotator.toml
|
|
|
|
|
|
|
|
|
|
REM Configure hook in settings.json
|
|
|
|
|
if not exist "%USERPROFILE%\.gemini\settings.json" (
|
|
|
|
|
(
|
|
|
|
|
echo {
|
|
|
|
|
echo "hooks": {
|
|
|
|
|
echo "BeforeTool": [
|
|
|
|
|
echo {
|
|
|
|
|
echo "matcher": "exit_plan_mode",
|
|
|
|
|
echo "hooks": [
|
|
|
|
|
echo {
|
|
|
|
|
echo "type": "command",
|
|
|
|
|
echo "command": "plannotator",
|
|
|
|
|
echo "timeout": 345600
|
|
|
|
|
echo }
|
|
|
|
|
echo ]
|
|
|
|
|
echo }
|
|
|
|
|
echo ]
|
|
|
|
|
echo },
|
|
|
|
|
echo "experimental": {
|
|
|
|
|
echo "plan": true
|
|
|
|
|
echo }
|
|
|
|
|
echo }
|
|
|
|
|
) > "%USERPROFILE%\.gemini\settings.json"
|
|
|
|
|
echo Created Gemini settings at %USERPROFILE%\.gemini\settings.json
|
|
|
|
|
) else (
|
|
|
|
|
findstr /c:"plannotator" "%USERPROFILE%\.gemini\settings.json" >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
REM Merge hook into existing settings.json using node (ships with Gemini CLI)
|
|
|
|
|
where node >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 (
|
|
|
|
|
set "GEMINI_SETTINGS_PATH=%USERPROFILE%\.gemini\settings.json"
|
|
|
|
|
set "GEMINI_SETTINGS_FWD=!GEMINI_SETTINGS_PATH:\=/!"
|
Supply-chain hardening: version pinning, SLSA attestations, fix #506 (#512)
* feat(install): supply-chain hardening (#507) + fix Gemini crash on Windows (#506)
Closes #507 items 1-2 and fixes #506.
Issue #507 asked for version-pinned installs from a trusted source, immutable
releases, and build-provenance attestations. This commit ships:
- `--version v0.X.Y` / positional / `-Version` flag across all three installers
(bash, PowerShell, cmd) so users can pin to reviewed versions. Default stays
`latest` — every existing `curl | bash` / `irm | iex` invocation works
unchanged. install.cmd gained `--version` as an alias to its existing
positional form for surface-area consistency.
- SLSA build provenance attestations via `actions/attest-build-provenance`
(SHA-pinned to v4.1.0) in release.yml. Covers all 10 compiled binaries
(5 plannotator + 5 paste-service). Top-level workflow permissions tightened
from `contents: write` to `contents: read`, with per-job overrides where
needed. Attestation step is gated on tag pushes so PR dry-runs don't
pollute Sigstore's transparency log.
- Opt-in provenance verification in all three installers, resolved via a
three-layer precedence ladder:
1. CLI flag `--verify-attestation` / `-VerifyAttestation`
2. Env var `PLANNOTATOR_VERIFY_ATTESTATION=1`
3. Config `~/.plannotator/config.json` → `verifyAttestation: true`
4. Default off
Off-by-default matches every major ecosystem installer (rustup, brew, bun,
deno, helm) and avoids a UX failure for the majority of users who don't
have `gh` installed or authenticated. Security-conscious users get three
ergonomic opt-in paths. When enabled, the installer hard-fails if `gh` is
missing so opt-in is never silently skipped.
- `PlannotatorConfig.verifyAttestation?: boolean` added to
`packages/shared/config.ts`. Pure additive schema change; no runtime
consumer exists (the field is read only by the install scripts). No UI
surface — this is an OS-level power-user knob only.
- Documentation rewritten in README.md, apps/hook/README.md, and the
marketing install page with both pinned-version examples and a "Verifying
your install" section covering manual `gh attestation verify` and offline
`cosign verify-blob` paths.
- Release skill updated to note that the release pipeline now emits SLSA
attestations and (post-merge) GitHub Immutable Releases will be enabled
on the repo.
Issue #506 (install.cmd crash on Windows when Gemini is present):
Root cause was cmd.exe's `setlocal enabledelayedexpansion` eating `!` chars
in the embedded `node -e "..."` Gemini settings merge script. Cmd's Phase 2
parser treated `!s.hooks)s.hooks={};if(!` as a variable expansion, corrupting
the JS before node saw it. Fixed by rewriting the JS to use the `||` idiom
(`s.hooks = s.hooks || {}`) which contains no `!` characters — semantically
identical, and sidesteps cmd's parser entirely with no escape gymnastics and
no new dependencies.
Added regression test in scripts/install.test.ts that asserts the `||` form
is present and `if(!s.hooks)` is absent, so re-introducing the bug would
fail CI.
Test suite expanded from 23 to 29 tests covering:
- Gemini #506 regression
- Three-layer opt-in wiring assertions for all three installers
- install.sh guard check (the executable `gh attestation verify` call must
live behind the `verify_attestation -eq 1` gate, so the default path never
invokes gh)
- PlannotatorConfig schema assertion
Out of scope (tracked):
- Immutable Releases toggle in repo Settings (one-click, post-merge).
- SLSA Build L3 via `slsa-framework/slsa-github-generator` (requires
restructuring release.yml around a reusable workflow).
- Issue #507 item 3: UI update-cooldown setting.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review feedback
- docs: drop broken `cosign verify-blob` example. Verified against
Sigstore's docs that `cosign verify-blob` requires `--bundle` (or
`--signature` + `--certificate`); the shipped command provided neither
and could not have worked. Replaced with the canonical
`gh attestation verify --repo` flow (gh + auth required, but optional —
only needed if a user wants to manually audit provenance) and a link
to GitHub's offline-verification docs for advanced workflows. Applied
to README.md, apps/hook/README.md, and the marketing install page.
- docs: list per-platform binary paths in the manual verification
examples. The previous snippets hardcoded `~/.local/bin/plannotator`
even though install.ps1 writes to `%LOCALAPPDATA%\plannotator\` and
install.cmd writes to `%USERPROFILE%\.local\bin\` — Windows users
copying the snippet got file-not-found instead of a verification
result.
- install.sh: capture and surface `gh attestation verify` stderr on
failure instead of redirecting to /dev/null. Diagnosability matches
install.ps1, which already prints `$verifyOutput` on failure. The
most common failure mode (`gh auth login` not run) is now
immediately actionable instead of presenting as a generic
"verification failed" error.
- install.cmd: reject any unknown dash-prefixed token before the
positional fall-through. A typoed `--verify-attesttion` no longer
becomes `VERSION=--verify-attesttion` and 404s on a nonsensical
download URL — it fails fast with `Unknown option:` and a usage
hint. install.sh and install.ps1 already had equivalent guards
(case `-*)` arm and PowerShell's strict param block respectively).
All 29 install tests still pass.
For provenance purposes, this commit was AI assisted.
* test(ci): add Windows integration job for install.cmd
Address the reviewer gap flagged in PR #512: the unit tests in
scripts/install.test.ts only do file-content string matching on Linux
and never execute cmd.exe, so the #506 fix (rewriting the embedded
`node -e` Gemini merge to use `x = x || {}` instead of `if(!x)x=...`)
was shipped without any runtime coverage. The previous CI only had
ubuntu-latest runners.
New `install-cmd-windows` job on `windows-latest`:
1. Seeds a fake `~/.gemini/settings.json` with a pre-existing non-
plannotator hook plus unrelated top-level keys (theme, general).
The fixture mirrors the shape of a real Gemini settings.json but
uses only obviously-fake values and contains no secrets.
2. Runs `scripts\install.cmd v0.17.1 --skip-attestation` end-to-end
through real cmd.exe. This exercises the parser under
`enabledelayedexpansion`, the embedded `node -e` merge script,
and the full install flow.
3. Parses the post-install settings.json with PowerShell and asserts:
- The plannotator hook was added to hooks.BeforeTool.
- The pre-existing fixture hook is still present (regression guard
for the original #506 bug, where cmd ate the `!` in
`if(!s.hooks.BeforeTool)s.hooks.BeforeTool=[]` and wiped existing
arrays).
- Unrelated top-level keys (`theme`, `general.ciFixtureSentinel`)
survived the merge untouched.
4. Separately exercises the new unknown-flag rejection added in the
previous commit: invokes `install.cmd --verify-attesttion` (typo)
via Start-Process and asserts exit code != 0. Before the review
fix this would have silently set `VERSION=--verify-attesttion`
and 404'd on the download.
The job runs in parallel with the existing ubuntu `test` job (no
deps, independent runner). Uses the v0.17.1 release as the binary
source — that release is pre-PR, so the test is stable against
release drift and is testing install.cmd's CODE, not any specific
binary.
This closes the CI gap where install.cmd had effectively zero
runtime coverage and the original #506 bug could have recurred
without anyone noticing until a user reported it.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): capture gh stderr on failure (consistency with install.sh)
Self-review catch: the PR #512 reviewer flagged install.sh for
redirecting `gh attestation verify` output to /dev/null, which
swallowed actionable error messages (auth missing, network issue,
attestation not yet propagated) behind a generic "verification
failed" line. I fixed install.sh in the previous review-fix commit
but missed that install.cmd had the exact same pattern:
gh attestation verify "!TEMP_FILE!" --repo !REPO! >/dev/null 2>&1
Same bug, same consequence, same fix. cmd doesn't have bash's
`$(cmd)` or PowerShell's `& cmd 2>&1` output capture, so we redirect
to a temp file and `type` it on failure, then clean up in both
branches:
gh attestation verify ... > "%TEMP%\gh-output.txt" 2>&1
if !ERRORLEVEL! neq 0 (
type "%TEMP%\gh-output.txt" >&2
del "%TEMP%\gh-output.txt"
echo Attestation verification failed! >&2
...
)
del "%TEMP%\gh-output.txt"
All three installers now surface gh's actual error message on
failure, which makes the most common failure mode (`gh auth login`
not run) immediately diagnosable on every platform.
Note: this code path is not exercised by the new Windows CI
integration job because that job passes `--skip-attestation`, and
exercising the gh verify path would require an attestation for
v0.17.1 to exist — which it doesn't, since v0.17.1 was released
before this PR added the attestation step. The fix will first
become CI-testable against the first post-merge release that
carries a provenance bundle.
For provenance purposes, this commit was AI assisted.
* fix(install): address second review pass on PR #512
Five findings, all verified against the actual code:
- **AGENTS.md env var table** (reviewer: "CLAUDE.md"; it's a symlink to
AGENTS.md) was missing PLANNOTATOR_VERIFY_ATTESTATION. Added with an
explicit note that it's read by the install scripts only, not the
runtime binary — since every other entry in that table is a runtime
env var, the distinction matters.
- **install.cmd unknown-flag guard metacharacter injection.** The
previous guard ran `echo %~1 | findstr /b "[-]"`, where %~1 is
unquoted before the pipe. A user passing `install.cmd "--bad&calc"`
would have cmd expand %~1 to `--bad&calc`, see the `&` as a command
separator, and execute `calc` as a side effect before the flag
check. Not a remote exploit (user already has shell exec), but a
defensive coding weakness in supply-chain hardening code.
Replaced with a variable-assigned substring test using delayed
expansion — `set "CURRENT_ARG=%~1"` preserves metacharacters
literally inside the `"..."` set syntax, and `!CURRENT_ARG:~0,1!`
extracts the first char without any subprocess. This also fixes the
same bug in the error-message echo, which previously echoed the
unquoted `%~1` and re-triggered metacharacter interpretation in the
error path itself. The echo now uses `"%~1"`.
Note: the reviewer's proposed one-liner `if "%~1:~0,1%"=="-"` was
syntactically invalid — cmd's `:~start,length` substring modifier
does not work on positional parameters, only on regular variables.
A variable assignment is necessary.
- **install.cmd unquoted --repo argument** in the `gh attestation
verify` call. TEMP_FILE was quoted but REPO was not. REPO is
hardcoded to `backnotprop/plannotator` so not exploitable, but
inconsistent with install.sh (which quotes `"$REPO"`). One-char
fix: `--repo "!REPO!"`.
- **test.yml intentional-typo drift hazard.** The unknown-flag
regression test invokes `install.cmd --verify-attesttion`
(missing an `a`). The only assertion was `$p.ExitCode -eq 0`. If
a future typo-sweep "fixes" the misspelling to the valid
`--verify-attestation`, install.cmd would accept the flag,
proceed to download the latest release, run `gh attestation
verify` against it, and — because v0.17.1 pre-dates the
attestation step — fail with a different non-zero exit. Both
paths exit 1, so the test would silently drift from "guard
works" to "gh attestation verify fails on pre-PR release"
without anyone noticing.
Two-part fix:
1. Explicit comment marking the misspelling as intentional
("do not correct during a typo sweep").
2. Redirect stderr to a temp file and assert it contains
"Unknown option:" — the actual discriminator between the
guard triggering and any other failure mode that happens
to exit non-zero.
- **README.md verification block was too long** for the main
README. Trimmed from ~33 lines (intro + 3 code blocks + opt-in
mechanisms + precedence notes) to a single sentence that links
to the canonical marketing installation docs where the full
content already lived. Same treatment applied to
apps/hook/README.md for consistency. The marketing docs are
unchanged and remain the single source of truth for
verification workflows.
All 29 install tests still pass. The Windows CI integration job's
new stderr assertion will exercise the harder guard on the next
push.
For provenance purposes, this commit was AI assisted.
* fix(install): tighten attestation verify with --source-ref and --signer-workflow
Addresses PR #512 review cycle 3 finding that repo-scoped verification
alone doesn't bind the downloaded binary to the specific tag the user
requested. A misattached release asset would pass the old check
because the wrong binary would still carry a valid attestation for
its own (wrong) commit.
GitHub's own docs explicitly recommend both constraints:
"The more precisely you specify the identity, the more control you
will have over the security guarantees. Ideally, the path of the
signer workflow is also validated."
— https://cli.github.com/manual/gh_attestation_verify
All three installers now pass:
--source-ref "refs/tags/<requested-tag>"
Enforces that the git ref the attestation was produced from
matches the tag the installer asked for. Closes the
misattached-asset gap.
--signer-workflow backnotprop/plannotator/.github/workflows/release.yml
Enforces that the attestation was signed by our release workflow
file specifically, not any workflow in the repo. GitHub treats
this flag as a regex (see cli/cli#9507) so future refactors can
broaden the match without breaking version-pinned installs to
historical releases.
Also addresses the sibling finding that install.cmd used a fixed
%TEMP%\gh-output.txt temp filename while the rest of the script
uses %RANDOM% for uniqueness. Renamed to
%TEMP%\plannotator-gh-%RANDOM%.txt, matching the established pattern
and removing a theoretical race between concurrent invocations.
New test in install.test.ts asserts all three installers pass
--source-ref and --signer-workflow with the expected values. 30
tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 4 (parser edges, ps1 stream, docs)
Five findings, all verified against actual code. One bonus fix in
install.sh for a sibling bug the reviewer flagged only in install.cmd.
install.ps1: `Write-Host $verifyOutput` on attestation failure wrote
gh's diagnostic to PowerShell's Information stream (stream 6), which
is silently dropped when CI pipelines capture stderr. Replaced with
`[Console]::Error.WriteLine($verifyOutput)` — direct stderr handle,
matches the behavior of `echo ... >&2` in install.sh and `type ...
>&2` in install.cmd.
install.sh + install.cmd: `--version --some-other-flag` used to set
VERSION to the flag name (e.g. VERSION=--verify-attestation), which
then tried to download tag `v--verify-attestation` and 404'd. The
empty-check on `$2`/`%~2` didn't catch dash-prefixed values. Added
an explicit dash-prefix check that returns a clean "--version
requires a tag value, got flag: X" error instead of degrading into
a cryptic download failure.
install.sh + install.cmd: mixing `--version v1.0.0 stray` used to
silently overwrite VERSION with "stray" because the positional
branch unconditionally assigned VERSION=$1. Added a VERSION_EXPLICIT
sentinel that's set to 1 when --version is seen, and the positional
branch now errors with "Unexpected positional argument: X (version
already set)" when it sees a token while the sentinel is set. Same
sentinel is also set by the positional branch itself, so passing
two positional version tokens also errors out cleanly.
Note: the reviewer flagged the positional-overwrite bug only in
install.cmd, but install.sh had the identical issue (same
unconditional `VERSION="$1"` in the `*)` arm) and the same dash-
check gap in both its `--version <val>` and `--version=<val>`
branches. Fixing both installers symmetrically — inconsistency
here would just trigger another review round.
marketing/installation.md: the "Verifying your install" prose
promised a "cryptographic link to the exact commit and workflow
run," but the example commands only passed `--repo`, which just
proves the artifact came from some workflow in our repository.
The installer now constrains with `--source-ref` and
`--signer-workflow` after review cycle 3, so the docs were out of
sync with the actual installer behavior. Updated all three
platform examples (bash, pwsh, cmd) to include the tighter flags
with a placeholder (`vX.Y.Z`) and a sentence explaining what the
extra flags actually buy the user. README.md and
apps/hook/README.md are already link-only after cycle 2 and don't
need changes.
install.test.ts: two new tests.
- Regression guard asserts install.sh and install.cmd contain the
VERSION_EXPLICIT sentinel, the dash-prefix error message, and
the "Unexpected positional argument" guard. Anyone removing
any of these in a future cleanup would fail CI.
- Regression guard asserts install.ps1 uses
[Console]::Error.WriteLine and does NOT use Write-Host for
verifyOutput.
32 tests pass (was 30). Smoke-tested install.sh with
`--version --verify-attestation` and `--version v1.0.0 stray` —
both now exit 1 with clean usage errors instead of silent
download failures.
For provenance purposes, this commit was AI assisted.
* fix(install): address PR #512 review cycle 5
Five code/doc fixes, all verified against actual code. Finding 1 from
the review (opt-in verification unusable until a post-merge release is
cut) is correct but not actionable — it's inherent to how SLSA
attestations work and the only "fix" is timing + release cadence.
install.ps1: `[Console]::Error.WriteLine($verifyOutput)` silently
converted multi-line gh output to the literal string "System.Object[]"
— the opposite of what cycle 4's Write-Host fix was supposed to do.
`& gh ... 2>&1` captures multi-line output as an object[] array;
passing the array directly to [Console]::Error.WriteLine binds to the
WriteLine(object) overload and calls ToString() on the array. Fixed by
piping through Out-String first (and TrimEnd to drop the trailing
newline it adds). Confirmed against Sigstore/PowerShell docs and the
Delft Stack array-to-string guide.
install.cmd: replaced `echo !TAG! | findstr /b "v"` with a substring
test `if not "!TAG:~0,1!"=="v"`. Same metacharacter-injection class as
the parser bug fixed in cycle 2 — piping an unquoted expanded variable
re-exposes cmd's & | > < operators in the value before the pipe runs.
Inconsistent to leave this one instance using the unsafe pattern when
every other comparable check in the script uses the substring idiom.
install.cmd: randomized the two remaining deterministic temp file
paths — %TEMP%\release.json and %TEMP%\plannotator-<tag>.exe — to
match the %RANDOM% pattern already used by GH_OUTPUT. Closes two
gaps at once: concurrent-invocation collisions (real for automated
upgrade tooling) and same-user symlink pre-placement (the SHA256
check passes on authentic content, but a symlink at the predictable
path would redirect where curl writes the binary before the install
move runs).
All three installers: reject --verify-attestation and
--skip-attestation together as mutually exclusive instead of trying
to guess which the user meant. Previously install.sh/cmd took last-
on-command-line wins and install.ps1 took a fixed-priority Skip-
always-wins (documented but inconsistent with the other two). No
sane user passes both flags — fast-failing with a clear "mutually
exclusive" error is better than silently picking one and hoping it
matches intent. Guards live inline in both arms of the bash/cmd
parsers and right after the PowerShell param block.
test.yml: added a comment block on the install.cmd v0.17.1 pin
explaining why that version was chosen, why `latest` isn't used,
what the prerequisites are for bumping it, and what failure mode
to expect if the pinned release is ever removed. No behavior
change — the existing pin stays. Addresses the reviewer's concern
that the dependency was undocumented.
install.test.ts: four new regression guards.
- Asserts install.ps1 uses Out-String (not bare [Console] call
on raw $verifyOutput) for multi-line gh output
- Asserts all three installers reject the --verify+--skip combo
with a "mutually exclusive" error and install.ps1 has the
`$VerifyAttestation -and $SkipAttestation` guard
- Asserts install.cmd uses randomized temp paths for release.json
and the binary download, and that the old deterministic paths
are gone
- Asserts install.cmd uses the substring test for v-prefix
normalization and does not pipe echo|findstr for that check
35 install tests pass (was 32). Smoke-tested the bash mutex guard
in both orders — both fail fast with "mutually exclusive" and
exit 1 regardless of which flag appears first.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): randomize checksum temp path + tighten test assertions
Self-review catch on top of the cycle 5 commit:
- `%TEMP%\checksum.txt` (lines 164/172/174) was still a fixed
predictable path. Same concurrency + symlink-pre-placement class
as release.json and TEMP_FILE that cycle 5 fixed. Inconsistent to
fix two of three and leave the third. Renamed to
`%TEMP%\plannotator-checksum-%RANDOM%.txt` matching the established
pattern. The reviewer didn't flag this one — I missed it during
the cycle 5 sweep.
- Tightened the Out-String regression test from a weak "Out-String
appears somewhere in the file" check to a regex matching the
specific `$verifyOutput | Out-String` wiring. Previous assertion
would have passed even if some future bug accidentally wrapped
the mutex-guard string literal in Out-String while leaving
$verifyOutput unprotected.
- Expanded the randomized-temp-paths test to cover all four curl
download targets (release.json, binary, checksum sidecar, gh
output capture) rather than the two originally in scope, and to
assert the old fixed paths (including checksum.txt) are gone.
35 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): escape ! in Claude Code slash command files
Pre-existing bug flagged in PR #512 review cycle 6. install.cmd writes
the three Claude Code slash command files (plannotator-review.md,
plannotator-annotate.md, plannotator-last.md) via `echo` lines inside
`setlocal enabledelayedexpansion`. cmd.exe's Phase 2 parser strips
unmatched `!` characters — so lines like:
echo !`plannotator review $ARGUMENTS`
ended up in the written file as:
`plannotator review $ARGUMENTS`
without the leading `!`. The `!` prefix is what tells Claude Code to
execute the backtick block as a shell command; without it, Claude Code
renders the line as inline markdown code and the slash command is a
silent no-op. The install appeared to succeed, but every Windows cmd
user got three broken slash command files.
install.sh (single-quoted heredocs) and install.ps1 (single-quoted
here-strings) write the `!` correctly because their respective
literal-string idioms bypass shell expansion entirely. install.cmd
has no single-quote-literal equivalent — its escape hatch is `^!`.
The Gemini section of install.cmd (lines 482, 495) already uses
`^!` correctly; the Claude Code section didn't until now.
Fix: three characters — `echo !` → `echo ^!` on lines 334, 351, 368.
Brings install.cmd into parity with the other two installers. No
divergence introduced; existing divergence removed.
Two regression guards added:
- Unit test in install.test.ts asserts install.cmd contains the
escaped form for all three command files and does not contain
the unescaped form.
- New step in the Windows CI integration job reads back each
generated .md file from %USERPROFILE%\.claude\commands\ and
asserts it contains the literal `!`\`plannotator` prefix. Catches
the bug at the actual file-write level on a real Windows runner,
not just via source-code grep.
36 install tests pass (was 35).
Note: the broader architectural issue — all three installers carry
hand-typed duplicates of command content that already lives at
apps/hook/commands/*.md — is deferred to a follow-up issue. The
cmd bug is the visibly-broken symptom; the deduplication is the
long-term fix.
For provenance purposes, this commit was AI assisted.
* fix(install.cmd): double-caret escape for ! in slash command echoes
The previous fix used `echo ^!` for the three Claude Code slash command
files. The Windows CI integration job's new file-readback assertion
proved this is wrong: the generated plannotator-review.md still landed
with no `!` prefix, making the slash command a silent no-op as before.
Root cause: cmd has two escape phases under enabledelayedexpansion.
Phase 1 (parse time): `^` escapes the next char. `^!` → `!`.
The caret is consumed.
Phase 2 (delayed expansion): the remaining bare `!` is an unmatched
variable reference and gets stripped.
Single `^!` dies in Phase 2 because Phase 1 already ate the caret.
Double `^^!` survives: Phase 1 reduces `^^` to `^` (leaving `^!`),
Phase 2 treats the caret as an escape for `!` and emits a literal.
Cycle 6's fix got the direction right but the arithmetic wrong. The
new file-readback assertion in test.yml caught it on the first real CI
run, which is exactly why that assertion was added.
Also fixes the Gemini slash command echoes (lines 482, 495) which used
the identical incorrect `^!` pattern. The review comment flagged
Gemini as "correct" based on source-reading alone; there was never
any CI coverage for the Gemini file contents, and the Gemini section
was silently broken for the same reason. Both sections now use `^^!`.
Unit test updated to assert the double-caret form on all five echo
lines (three Claude Code, two Gemini) and reject both the unescaped
and single-caret variants.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): fall back to x64 on ARM64 Windows instead of 404ing
Pre-existing bug surfaced in PR #512 review cycle 7.
install.ps1 detected ARM64 correctly and set $arch=arm64, constructing
a URL for plannotator-win32-arm64.exe — which doesn't exist in any
release. The release pipeline only builds bun-windows-x64 (release.yml
line 88), so there is no native ARM64 Windows binary to download.
With $ErrorActionPreference=Stop set at the top of the script, the
resulting 404 on Invoke-WebRequest threw a terminating error and the
install aborted with a stack trace. ARM64 Windows PowerShell users
could not install plannotator at all.
Meanwhile install.cmd, which hardcodes PLATFORM=win32-x64 and lets
ARM64 hosts pass the arch check, silently installs the x64 binary
and relies on Windows 11's x86-64 emulation layer to run it. This is
accidentally the useful behavior — imperfect, but the user gets a
working install instead of a hard failure.
This commit brings install.ps1 into parity with install.cmd's
(accidentally correct) behavior:
- On 64-bit Windows, $arch is unconditionally "x64" — no more
branch for arm64 that would download a nonexistent binary.
- When PROCESSOR_ARCHITECTURE == ARM64, Write-Host prints a notice
telling the user they're getting the x64 binary via Windows
emulation so the behavior isn't silent.
- 32-bit Windows still errors out (unchanged).
Both Windows installer paths now produce a working install on both
x64 and ARM64 hosts. No release pipeline changes. No new binaries.
The test `detects ARM64 architecture` used to be a weak string-
presence check that passed whether the ARM64 branch selected arm64
or x64. Rewrote it to assert the actual new contract: ARM64 is
detected (for the notice), $arch is hardcoded to "x64", and the
previous `{ "arm64" }` branch is gone so the regression can't
silently return.
Native ARM64 Windows builds tracked as a follow-up — requires
verifying Bun's Windows ARM64 target support and adding
bun-windows-arm64 to the release matrix.
For provenance purposes, this commit was AI assisted.
* fix(install): pre-flight MIN_ATTESTED_VERSION guard + placeholder docs
PR #512 cycle 7 review surfaced that opt-in provenance verification was
dead-on-arrival for the window between this PR merging and the first
post-merge release:
- The docs showed `--version v0.17.1` as the pinned example. v0.17.1
was cut before this PR added attestation generation to release.yml,
so any user copy-pasting the example AND enabling verification
would hit a cryptic `gh: no attestations found` error and a hard
install failure.
- Default installs with verification enabled (via flag, env var, or
config file) resolve `latest` to v0.17.1 and hit the same failure
with no user-visible pinned version to "blame."
Medium fix (better error message) was dismissed as lipstick — the
install still fails, just with nicer wording. This is the maximum fix
that actually prevents the failure path by checking the resolved tag
against a hardcoded floor BEFORE downloading.
## Changes
`scripts/install.sh`:
- New `MIN_ATTESTED_VERSION="v0.18.0"` constant near the top
- New `version_ge` helper using `sort -V` (handles v0.9.0 vs v0.10.0)
- Moved three-layer verification resolution (config → env → flag) to
before the download so $verify_attestation is known in time to
gate network work
- New pre-flight check: if verification is requested and the resolved
tag is older than MIN_ATTESTED_VERSION, fail fast with a clean
message listing recovery options (pin to newer version,
--skip-attestation, or unset the env var / config). No binary
download, no wasted SHA256 check.
- Late `gh attestation verify` block now only handles the gh call
itself — resolution and pre-flight moved upstream.
`scripts/install.ps1`:
- New `$minAttestedVersion = "v0.18.0"` constant
- Pre-flight guard in the verification branch using PowerShell's
[version] class for proper numeric comparison
- Same error message content as install.sh
`scripts/install.cmd`:
- New `set "MIN_ATTESTED_VERSION=v0.18.0"` near REPO setup
- Pre-flight guard shells out to PowerShell for semver comparison
— Windows 10+ ships `powershell.exe` always, so no new runtime
dependency. Hand-parsing semver in cmd was tried and rejected as
too fragile for prerelease tags and non-numeric components.
`apps/marketing/.../installation.md`, `apps/hook/README.md`,
`README.md`, `scripts/install.sh --help`:
- Replaced every user-facing `v0.17.1` example with `vX.Y.Z`
placeholder. The placeholder pattern already exists in the
"Verifying your install" section, so this is just consistency.
- install.sh --help adds a link to the releases page so users know
where to find actual tag values.
`.agents/skills/release/SKILL.md`:
- New Phase 4 checklist step: before shipping the first attested
release, verify MIN_ATTESTED_VERSION in all three installers
matches the tag being cut. The constant is bumped ONCE and never
again — it's a permanent floor, not a moving target. If the first
post-merge release is not v0.18.0, the skill updates the constant
in the same commit as the version bump so the installers served
from plannotator.ai activate the new floor at the same moment
the first attested release becomes fetchable.
`scripts/install.test.ts`:
- New test asserts all three installers hardcode MIN_ATTESTED_VERSION,
use appropriate version comparison for their dialect, and contain
the "predates" error message
- New test asserts install.sh and --help text no longer contain
`v0.17.1` as a pinned example
38 install tests pass (was 36). Smoke-tested install.sh end-to-end:
- `--version v0.17.1 --verify-attestation` → pre-flight rejects
cleanly, no download attempted, exit 1 with actionable error
- `--version v0.18.0 --verify-attestation` → pre-flight passes,
script proceeds to download (404 as expected since v0.18.0 is
not yet released)
- `--version v0.17.1` (no verify) → pre-flight skipped, normal
download path
For provenance purposes, this commit was AI assisted.
* fix(install): close PS injection + move Windows pre-flight before download
PR #512 review cycle 8 raised three related findings, all verified
against actual code.
## Critical: PowerShell command injection in install.cmd (Finding 2)
Line 228 of the previous install.cmd passed the version comparison
to PowerShell by interpolating delayed-expansion variables directly
into the command string between single-quoted literals:
for /f "delims=" %%i in ('powershell -NoProfile -Command "try {
if ([version]'!TAG_NUM!' -ge [version]'!MIN_NUM!') { 'yes' }
} catch {}"') do set "VERSION_OK=%%i"
The arg parser rejected leading-dash values but not quotes or
semicolons, so a user passing
install.cmd --version "0.18.0'; calc; '0.18.0"
produced the PowerShell command
try { if ([version]'0.18.0'; calc; '0.18.0' -ge [version]'0.18.0')
{ 'yes' } } catch {}
PowerShell permits statement sequences inside `if` condition
parentheses — the last value is used — so `calc` executed as a side
effect during the first evaluation phase. Attacker-controlled
--version from a CI/CD wrapper (PR titles, external tag sources,
etc.) equals arbitrary code execution as the invoking user.
Fixed by passing the version strings via environment variables
($env:TAG_NUM, $env:MIN_NUM) instead of interpolating them into
the PowerShell command string. PowerShell reads $env: values as
raw strings and never parses them as code. The [version] cast
throws on invalid input, catch {} swallows it, VERSION_OK stays
empty, and the guard rejects — safe fail with a slightly less
helpful but correct error message.
## Structural: Windows pre-flight ran post-download (Findings 1 & 3)
install.sh was already restructured in the previous commit to run
the three-layer resolution + MIN_ATTESTED_VERSION guard BEFORE the
binary download, so users hit the "predates attestation support"
error without wasting bandwidth.
install.ps1 and install.cmd drifted — their resolution and
pre-flight blocks stayed in their original post-SHA256 positions,
meaning the binary was always downloaded and SHA256-verified even
when the requested tag was doomed to fail provenance verification.
The "Pre-flight: reject the verification request before
downloading" comments were lies copied from install.sh.
This commit moves both Windows installers' resolution + pre-flight
blocks upstream of the download:
install.ps1: resolution + pre-flight now run immediately after
`Write-Host "Installing plannotator $latestTag..."`, before
$tmpFile is created or Invoke-WebRequest runs. The late
gh-call block keeps only the gh attestation verify call itself.
install.cmd: same restructure. The late block keeps only the
where-gh check and gh invocation. The `del "!TEMP_FILE!"`
calls inside the rejection branch are gone (TEMP_FILE doesn't
exist yet when the guard runs).
## Tests
Added two new regression guards to scripts/install.test.ts:
1. Order-aware check for all three installers: the resolution
block's opening line must appear textually BEFORE the curl /
Invoke-WebRequest download line. Uses indexOf to compare
positions. Catches any future regression that drifts the
pre-flight back after download.
2. Injection-safe pattern check for install.cmd: asserts the
PowerShell command references $env:TAG_NUM / $env:MIN_NUM and
does NOT interpolate !TAG_NUM! / !MIN_NUM! between single
quotes in any [version] cast.
40 install tests pass (was 38). Smoke-tested install.sh with
--version v0.17.1 --verify-attestation — rejects cleanly with no
download, same as before.
For provenance purposes, this commit was AI assisted.
* fix(install): close cycle-9 gaps — CI coverage, v-strip, prerelease handling
PR #512 cycle 9 review surfaced three real findings, all verified.
## Finding 1 (important): Windows CI never exercised the attestation path
The Windows integration job ran `install.cmd v0.17.1 --skip-attestation`,
which bypasses every bit of logic this PR shipped: three-layer opt-in
resolution, MIN_ATTESTED_VERSION pre-flight, $env:-based PowerShell
version comparison, and the gh attestation verify call. A runtime bug
in any of those paths would not be caught by CI.
`--skip-attestation` was passed intentionally because v0.17.1 predates
attestation support — running without it hits the pre-flight and
rejects. But that's the point: the REJECTION path is a real, valid end
state we can assert against. The previous test conflated "install
should succeed" with "test should pass"; the fix is to assert the
correct behavior for an old version.
Added a new CI step that runs `install.cmd v0.17.1 --verify-attestation`
via Start-Process with stderr redirection to a temp file, then asserts:
- exit code != 0 (pre-flight rejected)
- stderr contains "predates" (rejection came from our guard, not
some other failure mode like a network error or gh missing)
This exercises on a real cmd.exe:
- setlocal enabledelayedexpansion parser under the guard
- three-layer resolution reaching the CLI flag layer
- the :~1 substring (instead of the previous :v= global substitution)
- the pre-release tag detection (negative path for stable tags)
- the PowerShell shell-out with $env:TAG_NUM / $env:MIN_NUM
- the [version] -ge comparison returning false
- the "predates" error message block
Can't test the success path (valid attested release) until the first
post-merge release exists. Tracked for follow-up.
## Finding 2 (nit): !TAG:v=! is a global substitution, not anchored
cmd's delayed-expansion string-substitution syntax `!VAR:str=repl!`
replaces every occurrence of `str` globally. For all current semver
tags (vX.Y.Z) this happens to strip exactly one `v` by coincidence.
A hypothetical future tag like v1.0.0-rev2 would become 1.0.0-re2,
which [System.Version] can't parse, silently misclassifying the
failure as "predates attestation support" (see Finding 3).
install.ps1 line 121 uses `-replace '^v', ''` which is properly
regex-anchored. install.cmd had no anchored equivalent.
Fixed by using `!TAG:~1!` — substring from index 1 — which drops
exactly the first character. Safe because TAG is guaranteed to start
with `v` by the normalization step upstream (line ~141).
## Finding 3 (nit): Pre-release tags misdiagnosed on Windows
[System.Version] doesn't support semver prerelease or build-metadata
suffixes (e.g. v0.18.0-rc1). It throws on any `-` in the version
string. The catch blocks in both Windows installers handled the
throw but surfaced wrong/confusing errors:
install.sh: handles prereleases correctly via `sort -V` (POSIX
version sort is semver-aware) — no issue.
install.ps1: caught and printed "Could not parse version tags for
provenance check" — accurate but doesn't explain WHY.
install.cmd: swallowed silently, VERSION_OK stayed empty, printed
"predates attestation support" — actively wrong, the problem
isn't the version's age.
Fixed in both Windows installers by detecting `-` in the tag BEFORE
attempting the [version] cast:
install.ps1: `if ($latestTag -match '-')` → dedicated error
install.cmd: `if not "!TAG_NUM!"=="!TAG_NUM:-=!"` (native
substitution check, no subshell, no metacharacter risk)
Both emit a clear "pre-release tags aren't currently supported for
provenance verification on Windows" message pointing users at
--skip-attestation or a stable tag. Windows has no built-in semver
comparator; adopting one would require NuGet or a custom parser.
Explicit rejection with honest diagnosis is the pragmatic choice.
## Tests
Three new regression guards in install.test.ts:
1. `install.cmd strips leading v via substring, not global
substitution` — asserts `!TAG:~1!` is present and `!TAG:v=!`
is gone.
2. `both Windows installers reject pre-release tags with a
dedicated error` — asserts both scripts contain the
"Pre-release tags" error message and the appropriate
detection pattern for their dialect.
3. The new test.yml CI step doubles as a runtime regression
guard — any break in the cmd pre-flight path that no longer
matches "predates" in stderr, or returns 0, fails CI.
42 install tests pass (was 40). Windows CI will now exercise the
pre-flight rejection path end-to-end for the first time.
For provenance purposes, this commit was AI assisted.
* fix: cycle-10 review — split attest job, assert binary preservation, misc
PR #512 cycle 10 raised four findings, all verified.
## Finding 1: id-token/attestations permissions granted to build on PRs
The build job in release.yml had `id-token: write` and
`attestations: write` at the job level with no conditional guard.
On PR triggers, those permissions were live for every build step
(checkout, bun install, bun build, compile) even though the
attestation step itself was gated by `if: startsWith(github.ref,
'refs/tags/')`. Narrow-but-real attack surface: a trusted
contributor's malicious PR injecting code into a build step could
mint an OIDC token authenticating as the repo identity. Fork PRs
are automatically protected (GitHub suppresses OIDC tokens on
forks), but same-repo contributor compromise is a realistic risk
in a project with external contributors.
Fixed by splitting attestation into its own job:
build: contents: read only. Runs on all triggers. Compiles
binaries and uploads them as the `binaries` artifact.
No OIDC capability anywhere in the job.
attest: needs: build, if: tag push only. contents: read +
id-token: write + attestations: write. Downloads the
binaries artifact and runs attest-build-provenance.
Permissions are only live when we're actually producing
an attestation — never on PR dry-runs.
release: needs: attest (was: needs: build). Still tag-only. The
dependency chain guarantees the attestation exists in
the GitHub attestation store before the release's
binaries are published, closing the race window where a
user could pull the binary and gh attestation verify
would fail because the bundle hadn't propagated yet.
npm-publish: unchanged. Still needs: build. Still has id-token:
write for `npm publish --provenance`. The reviewer
flagged only the build job; npm-publish's id-token
grant is scoped to that one job and is actually used by
the provenance flag.
## Finding 2: CI test promised a binary-preservation check but didn't do one
The `Attestation pre-flight rejects v0.17.1` step contained a
multi-line comment promising to verify the rejected run didn't
overwrite the previously-installed binary. No assertion code
followed — just a Write-Host success line. The test claimed
more than it delivered.
Added actual baseline capture + comparison:
- Before running the rejection test, capture the binary's
SHA256 and LastWriteTime from the prior Gemini-merge step.
- After the rejection, recompute both and assert they match.
- Any drift throws: catches future regressions that re-introduce
the post-download pre-flight pattern (the pre-flight correctly
rejects but only after downloading and overwriting the file).
## Finding 3: install.ps1 dead-code comment about flag precedence
Line 111 read "-SkipAttestation beats -VerifyAttestation if both
passed" but the upfront mutex guard (lines 13-16) exits 1 if both
flags are present. The "beats" scenario is unreachable. The
comment misleads a future reader into thinking the late ordering
handles the mutual exclusion and is safe to remove the early
guard — which would be backwards.
Replaced with a comment that explicitly notes the mutex guard at
the top of the script makes the two branches mutually exclusive
by construction.
## Finding 4: install.sh `cd` inside `&&` condition leaked CWD on failure
The skills-install block chained `git clone ... && cd ... && git
sparse-checkout set ...`. If clone succeeded but sparse-checkout
failed, the short-circuit skipped the `cd -` and `rm -rf
"$skills_tmp"` later ran with the shell's CWD still inside the
to-be-deleted directory. On Linux/macOS this silently "works" —
the inode is unlinked but the process keeps its cwd reference —
so nothing visibly breaks (all downstream code uses absolute
paths). But it's structurally wrong: install.ps1 and install.cmd
both use Push-Location/pushd for the same logic.
Restructured to run the entire clone → sparse-checkout → verify
→ copy sequence inside a single `(...)` subshell, with `cd`s
scoped to the subshell. The parent shell's CWD is unchanged
regardless of which step fails, so the subsequent `rm -rf`
always runs from a stable location. Any failure in the chain
short-circuits to the else branch with a clean skip message.
Also merged the two `[ -d ]` / `[ ls -A ]` guards into the
chain so the "apps/skills empty" case is now reported in the
skip message rather than being silently suppressed.
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* fix(install): set MIN_ATTESTED_VERSION to v0.17.2, remove skill bump note
Earlier cycles hardcoded MIN_ATTESTED_VERSION="v0.18.0" across the
three installers as a best-guess for the first post-merge release,
and I added a one-time bump instruction to the release skill as
insurance in case the guess was wrong.
The guess was wrong — the next release is v0.17.2 (patch bump,
not a minor bump). Updated the constant in all three installers and
the matching test assertions. No other version references in the
shipped error messages need changing because they read MIN_ATTESTED_VERSION
from the variable at runtime.
Also removed the "⚠️ One-time MIN_ATTESTED_VERSION bump" section
from .agents/skills/release/SKILL.md entirely. With the constant
now set to the actual next release tag, there's nothing for the
release agent to bump at release time — the constant is already
correct. Baking a one-time action into a recurring release skill
was the wrong place for it; every future release agent would read
the warning, confirm it's already set, and move on. Noise in a
workflow that's supposed to be tight.
If the next release version ever differs from v0.17.2 (e.g. we
decide to skip to v0.18.0 or go straight to v1.0.0), the PR cutting
that release will need to update MIN_ATTESTED_VERSION in the three
installers. That's an ad-hoc fix, not a recurring skill concern.
Smoke test with the new value:
- install.sh --version v0.17.1 --verify-attestation → rejects
with "first attested release is v0.17.2"
- install.sh --version v0.17.2 --verify-attestation → passes
pre-flight, proceeds to download (404 as expected since
v0.17.2 is not yet released)
42 install tests pass.
For provenance purposes, this commit was AI assisted.
* feat(release): ship native ARM64 Windows binaries
Bun v1.3.10 (February 2025) promoted bun-windows-arm64 from preview to
a stable cross-compile target, which makes native ARM64 Windows builds
a 15-line change instead of a project. Adopted immediately so ARM64
Windows users get native-speed binaries instead of the x86-64
emulation tax.
Earlier cycles of this PR shipped two temporary workarounds for the
absence of a native ARM64 binary:
- install.ps1 detected ARM64 and fell back to $arch="x64" with a
Write-Host notice that the user was running via emulation.
- install.cmd hardcoded PLATFORM=win32-x64 and let ARM64 hosts pass
the arch check without differentiation.
Both are now obsolete and have been replaced with real architecture
detection that selects the native binary.
## Changes
release.yml: Added `bun-windows-arm64` to the compile matrix for
both apps/hook/server/index.ts and apps/paste-service/targets/bun.ts.
Output files are plannotator-win32-arm64.exe and
plannotator-paste-win32-arm64.exe with matching .sha256 sidecars.
Upload-artifact already globs `plannotator-*` so no change there.
release.yml attest step: Added the two new ARM64 binaries to
subject-path so they're covered by the SLSA build provenance
attestation alongside the x64 builds. Both binaries sign with the
same Sigstore bundle as the rest of the matrix.
install.ps1: Restored the proper ARM64 detection that the earlier
fallback replaced. On 64-bit Windows, $arch is "arm64" when
PROCESSOR_ARCHITECTURE equals "ARM64", otherwise "x64". The
emulation-fallback Write-Host notice is gone — users now get
native binaries and don't need to be told about emulation.
install.cmd: Replaced the unconditional `set "PLATFORM=win32-x64"`
with a set of conditional assignments keyed off PROCESSOR_ARCHITECTURE
and PROCESSOR_ARCHITEW6432 (the latter covers the edge case of a
32-bit tool launching install.cmd on an ARM64 machine via WoW64).
PLATFORM is left empty if neither variable indicates AMD64 or ARM64,
which triggers the "does not support 32-bit Windows" error path.
The :arch_valid label and its gotos are gone — the new logic is
linear and doesn't need a label.
install.test.ts: Updated the install.ps1 ARM64 test to assert the
native arm64 branch (no more "runs via emulation" text) and added a
new install.cmd test verifying both PLATFORM branches are present.
43 install tests pass (was 42).
## CI coverage caveat
windows-latest is x86-64, so the Windows integration job still
exercises install.cmd against the x64 binary path. ARM64 has no CI
runner coverage yet — we're shipping ARM64 binaries on trust that
Bun's cross-compile produces working executables. That's the same
trust we extend to linux-arm64 builds (also x-compiled from an
ubuntu-latest runner). GitHub Actions does offer a windows-11-arm
runner that could be added later; tracked as follow-up since it has
availability and pricing implications.
Closes #517.
For provenance purposes, this commit was AI assisted.
* fix(install.ps1): detect ARM64 host through WoW64 too, matching install.cmd
Self-review catch on top of the ARM64 support commit. My install.ps1
architecture detection only checked \$env:PROCESSOR_ARCHITECTURE, which
reports the architecture the CURRENT PowerShell process is running
under — not the host architecture. On ARM64 Windows, a 32-bit
PowerShell process (rare, but possible) would see
PROCESSOR_ARCHITECTURE=X86, miss the "ARM64" branch, fall through to
\$arch = "x64", and download the emulated x64 binary instead of the
new native arm64 build.
install.cmd already handles this correctly via PROCESSOR_ARCHITEW6432,
which is set only in 32-bit WoW64 processes and holds the host
architecture. install.ps1 was the odd one out.
Fixed by checking PROCESSOR_ARCHITEW6432 first and falling back to
PROCESSOR_ARCHITECTURE. Now both Windows installers follow the same
detection logic regardless of process bitness. Also added an explicit
error branch for unrecognized architectures (anything that isn't AMD64
or ARM64) instead of silently assuming x64.
Test updated to assert both env vars are referenced.
For provenance purposes, this commit was AI assisted.
* fix(install): cycle-12 review — consistency test, dead code, finally, docs
Four findings addressed. Two findings rejected.
## Finding 1 (nit): MIN_ATTESTED_VERSION triplicated without CI consistency
Added a cross-file consistency test in install.test.ts that extracts
the version literal from each of install.sh, install.ps1, install.cmd
via regex and asserts all three match. A future bump that updates
only one or two files now fails CI loudly. The per-file tests still
exist (they check each file contains the current literal), but the
new test catches drift where each file is internally consistent with
itself but differs from the others.
## Finding 4 (nit): Write-Error + exit 1 dead code in install.ps1
Verified against the actual file: $ErrorActionPreference = "Stop" is
set at line 8 and never modified. All six Write-Error sites are dead-
end paths — five outside any try/catch, one inside a catch block
(line 147) where Write-Error raises a new terminating error that
propagates past the catch and exits the script with code 1 (PowerShell
default). The `exit 1` lines that followed were never reachable.
Dropped the six unreachable `exit 1` lines. Added a comment at the
first occurrence explaining the Stop + Write-Error semantics so
future maintainers don't re-add them. Behavior is unchanged at
runtime — every error path still exits with code 1 via PowerShell's
default unhandled-terminating-error handling.
## Finding 5 (nit): Pop-Location not in finally block
Verified the reviewer's claim in install.ps1 lines 384-403. The
skills install wraps git clone, Push-Location, and Copy-Item calls
in a single try block, with Pop-Location on the success path. If
Copy-Item throws under ErrorActionPreference=Stop, catch runs
without popping, and the subsequent Remove-Item deletes a directory
the PowerShell location stack still points into.
A naive `finally { Pop-Location }` would introduce a new bug:
Pop-Location throws on an empty stack, which happens when git
clone silently fails and Push-Location is never reached. Used a
nested-try pattern instead:
try {
git clone ... # native, no throw
if (Test-Path "$skillsTmp\repo") { # guard against clone failure
Push-Location "$skillsTmp\repo"
try {
...operations...
} finally {
Pop-Location # always runs IF pushed
}
}
} catch {
Write-Host "Skipping..."
}
Traced all four failure modes:
- clone fails silently → repo dir missing → skip inner block → no
push, no pop → clean exit
- clone succeeds → push succeeds → operations fail → finally pops
→ outer catch fires
- clone + push + operations all succeed → finally pops cleanly
- push itself throws (permissions) → outer catch fires, nothing
to pop
## Finding 6 (P1): CMD/ps1 ARM64 breaks pinned pre-v0.17.2 tags
The original plan was a runtime x64-fallback on 404, but the simpler
product-level framing is: v0.17.2 is the first fully-supported version
for pinning. Pre-v0.17.2 tags predate native ARM64 Windows (no
win32-arm64 asset exists) and predate attestation support (pre-flight
rejects). Users pinning to older tags are outside the supported
matrix; the failure modes are explicit (404 / clean rejection), not
silent corruption.
Documented in the three install docs:
- apps/marketing/.../installation.md: full "Supported versions"
paragraph explaining the floor, what fails, and recovery paths
- README.md: one-line note folded into the existing provenance
sentence ("Version pinning, native ARM64 Windows, and SLSA
provenance are supported from v0.17.2 onwards — see installation
docs for details")
- apps/hook/README.md: same tight one-liner pattern
README.md and apps/hook/README.md stay bloat-free; the canonical
explanation lives in the marketing docs.
## Findings rejected
- **Finding 2 (P3, sort -V misorders prereleases):** plannotator
doesn't ship prerelease tags. A user pinning to a hypothetical
vX.Y.Z-rc1 would 404 at the download step before the sort -V
misordering matters. Moot in practice.
- **Finding 3 (important, sort -V is GNU-only):** FALSE POSITIVE.
Tested on macOS 26.3.1 running sort 2.3-Apple (197) — both -V
and --version-sort are supported and work correctly, including
for prerelease suffixes. Apple forked BSD sort and added -V
years ago. The reviewer's claim cites outdated reference
material about historical BSD sort.
44 install tests pass (was 43).
For provenance purposes, this commit was AI assisted.
* test: anchor MIN_ATTESTED_VERSION consistency regexes to line start
Self-review catch: the cross-file consistency test added in the prior
commit matched the assignment form anywhere in each file. No current
comment triggers a false positive, but a future comment like
`# Example: MIN_ATTESTED_VERSION="v0.17.0"` would match first and
shadow the real assignment, causing the test to report the wrong
value or pass when it shouldn't.
Hardened by adding /m flag and ^ anchor. The real assignments in all
three installers are flush-left at the top of their files, so
requiring line-start is both safe (won't reject current code) and
stricter (future comments with leading whitespace or other prefixes
are ignored).
44 tests still pass.
For provenance purposes, this commit was AI assisted.
* fix: cycle-13 review — checksum cleanup leak + Gemini CI coverage
Two findings addressed. Two pre-existing findings flagged but not
in scope.
## Finding 3 (nit): CHECKSUM_FILE leak on download failure
install.cmd's checksum download error path deleted TEMP_FILE but
omitted CHECKSUM_FILE. curl -o creates the output file before it
receives data, so a network failure or HTTP error leaves a 0-byte
or partial file in %TEMP% that the script never cleans up. The
symmetric cleanup for TEMP_FILE elsewhere in the script makes this
an accidental omission, not an intentional design choice.
Added `if exist "!CHECKSUM_FILE!" del "!CHECKSUM_FILE!"` inside the
error block, matching the existing cleanup discipline.
## Finding 1 (nit): Windows CI readback misses Gemini .toml files
The `Verify Claude Code slash command files contain the shell-
invocation prefix` step in the Windows integration job verified
the three `.md` files at %USERPROFILE%\.claude\commands\ but not
the two `.toml` files at %USERPROFILE%\.gemini\commands\. Both
sets of files use the `^^!` cmd escape pattern that this PR added,
and a future regression that drops a `^` from the Gemini echoes
would slip past CI even though install.test.ts catches it
statically.
Extended the readback step to also verify
plannotator-review.toml and plannotator-annotate.toml contain the
`!{plannotator ...}` invocation form. Same regression class, same
guard, same runner — the earlier Gemini-merge fixture step
already seeds ~/.gemini/settings.json, which causes install.cmd's
Gemini block to fire and write the .toml files alongside the
Claude Code ones, so no additional setup is required.
## Findings rejected (out of scope, pre-existing)
- **install.cmd vs install.ps1 install location divergence:** cmd
installs to %USERPROFILE%\.local\bin while ps1 installs to
%LOCALAPPDATA%\plannotator. A user who switches between the two
Windows installers ends up with hooks.json pointing at one
location and an orphan binary at the other. Pre-existing
structural divergence, requires picking a canonical location and
migrating users on whichever installer changes. Out of scope
for this PR.
- **install.sh Gemini merge throws on user's malformed JSON:** if
~/.gemini/settings.json is invalid JSON, the embedded `node -e`
call exits non-zero, set -e propagates, and the install aborts
mid-run after the binary is in place but before slash commands
are written. Pre-existing — the Gemini block predates this PR.
Worth a follow-up but not in scope here.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs: update stale v0.17.1 references in script comments to vX.Y.Z
Two cosmetic comment fixes flagged during the cycle-13 self-review.
The user-facing examples and docs were updated to vX.Y.Z in cycle 5,
but two inline code comments still referenced the old concrete version:
- scripts/install.sh:129 — "Positional form: install.sh v0.17.1
(matches install.cmd interface)"
- scripts/install.cmd:71 — "Positional form: install.cmd v0.17.1
(legacy interface)"
Both updated to vX.Y.Z so the in-code comments match the rest of the
documentation. No behavior change.
44 install tests pass.
For provenance purposes, this commit was AI assisted.
* docs(skill): update release skill platform/binary counts for ARM64 Windows
Two stale references in .agents/skills/release/SKILL.md after the
ARM64 Windows binaries were added:
- "5 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64)"
→ "6 platforms (macOS ARM64/x64, Linux x64/ARM64, Windows x64/ARM64)"
- "Compiles paste service binaries (same 5 platforms)"
→ "Compiles paste service binaries (same 6 platforms)"
- "Generates SLSA build provenance attestations for all 10 binaries"
→ "Generates SLSA build provenance attestations for all 12 binaries"
The first two predate this PR; the third was added in the cycle-1
commit and not bumped when the ARM64 Windows targets landed in the
ARM64 commit. All three corrected together so the release agent
sees an internally-consistent description of what the pipeline
actually does.
Verified against release.yml — 12 entries in the attest job's
subject-path list, 12 compile commands in the build job, all six
platforms (macOS arm64/x64, Linux x64/arm64, Windows x64/arm64)
for both plannotator and paste-service.
For provenance purposes, this commit was AI assisted.
2026-04-07 20:35:16 -07:00
|
|
|
node -e "const fs=require('fs');const s=JSON.parse(fs.readFileSync('!GEMINI_SETTINGS_FWD!','utf8'));s.hooks=s.hooks||{};s.hooks.BeforeTool=s.hooks.BeforeTool||[];s.hooks.BeforeTool.push({matcher:'exit_plan_mode',hooks:[{type:'command',command:'plannotator',timeout:345600}]});fs.writeFileSync('!GEMINI_SETTINGS_FWD!',JSON.stringify(s,null,2)+'\n');"
|
feat(gemini): add Gemini CLI plan review integration
* feat(gemini): add Gemini CLI plan review integration
Adds a new `apps/gemini-hook/` adapter that enables Plannotator plan
review for Gemini CLI users via the BeforeTool hook system.
The adapter reads the plan file from disk (Gemini provides a path, not
inline content), delegates to the shared @plannotator/server for the
browser-based review UI, and translates the decision back into Gemini's
hook output format.
Requires an upstream fix (google-gemini/gemini-cli#21802) that makes
`decision = "allow"` user policies work for exit_plan_mode, allowing
hooks to replace the built-in TUI approval dialog.
Includes:
- apps/gemini-hook/server/index.ts — stdin/stdout adapter
- apps/gemini-hook/hooks/ — policy TOML + settings snippet
- scripts/install.sh — Gemini binary download, policy install, settings config
For provenance purposes, this commit was AI assisted.
* refactor(gemini): use single binary with auto-detection instead of separate app
Removes apps/gemini-hook/ — the plannotator binary now auto-detects
Gemini CLI from stdin (plan_path = file on disk) vs Claude Code
(plan = inline content) and branches input parsing + output formatting.
Config fixtures live in apps/gemini/ (policy TOML + settings snippet).
Install script gates on ~/.gemini existing so Claude-only users are
unaffected.
For provenance purposes, this commit was AI assisted.
* test(gemini): add manual sandbox script for Gemini CLI integration
Three modes:
- --simulate: pipes BeforeTool JSON to hook, tests approve/deny output
- (default): runs local patched Gemini build
- --nightly: installs Gemini nightly and runs it
Backs up and restores ~/.gemini config on exit.
For provenance purposes, this commit was AI assisted.
* feat(gemini): add slash commands, marketing tab, and docs for Gemini CLI
- Add /plannotator-review and /plannotator-annotate slash commands (.toml)
- Install Gemini slash commands in all three install scripts (sh, ps1, cmd)
- Add Gemini tab to marketing landing page with icon
- Add Gemini CLI to top-level README install section
- Create apps/gemini/README.md with full setup and usage docs
- Remove stale dev:gemini script and regenerate bun.lock
For provenance purposes, this commit was AI assisted.
* fix(gemini): merge hook into existing settings.json instead of printing instructions
When ~/.gemini/settings.json already exists, use node to JSON-merge
the BeforeTool hook config rather than asking the user to do it manually.
Falls back to instructions only if node is unavailable.
For provenance purposes, this commit was AI assisted.
* fix(gemini): handle plan_filename rename and fix scoping bug
Gemini CLI nightly renamed plan_path to plan_filename in exit_plan_mode.
Accept both field names for forward/backward compatibility. Reconstruct
full plan path from transcript_path + session_id + plans/ + filename.
Also hoist planFilename variable out of try block so it's accessible
in the deny output path (was causing ReferenceError).
For provenance purposes, this commit was AI assisted.
* fix(gemini): dim approve button when annotations exist for Gemini CLI
Gemini's hook runner ignores systemMessage on the allow path, so
approve-with-feedback is silently dropped — same limitation as Claude
Code. Extend the existing UI gate to also apply for gemini-cli origin.
For provenance purposes, this commit was AI assisted.
* fix(gemini): add AGENT_CONFIG entry and fix sandbox simulate mode
Register "gemini-cli" in AGENT_CONFIG so the UI shows "Gemini CLI"
with proper badge styling instead of generic "Coding Agent" fallback.
Update sandbox simulate mode to match production input format:
use plan_filename instead of plan_path, include transcript_path,
and simulate the Gemini directory structure for path reconstruction.
For provenance purposes, this commit was AI assisted.
2026-04-02 15:24:10 -07:00
|
|
|
echo Added plannotator hook to !GEMINI_SETTINGS_PATH!
|
|
|
|
|
) else (
|
|
|
|
|
echo.
|
|
|
|
|
echo Add the following to your ~/.gemini/settings.json hooks:
|
|
|
|
|
echo.
|
|
|
|
|
echo "hooks": {
|
|
|
|
|
echo "BeforeTool": [{
|
|
|
|
|
echo "matcher": "exit_plan_mode",
|
|
|
|
|
echo "hooks": [{"type": "command", "command": "plannotator", "timeout": 345600}]
|
|
|
|
|
echo }]
|
|
|
|
|
echo }
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM Gemini slash commands (plannotator-*.toml) are copied from the sparse
|
|
|
|
|
REM checkout in the git-gated skills/commands block above, not written here.
|
feat(gemini): add Gemini CLI plan review integration
* feat(gemini): add Gemini CLI plan review integration
Adds a new `apps/gemini-hook/` adapter that enables Plannotator plan
review for Gemini CLI users via the BeforeTool hook system.
The adapter reads the plan file from disk (Gemini provides a path, not
inline content), delegates to the shared @plannotator/server for the
browser-based review UI, and translates the decision back into Gemini's
hook output format.
Requires an upstream fix (google-gemini/gemini-cli#21802) that makes
`decision = "allow"` user policies work for exit_plan_mode, allowing
hooks to replace the built-in TUI approval dialog.
Includes:
- apps/gemini-hook/server/index.ts — stdin/stdout adapter
- apps/gemini-hook/hooks/ — policy TOML + settings snippet
- scripts/install.sh — Gemini binary download, policy install, settings config
For provenance purposes, this commit was AI assisted.
* refactor(gemini): use single binary with auto-detection instead of separate app
Removes apps/gemini-hook/ — the plannotator binary now auto-detects
Gemini CLI from stdin (plan_path = file on disk) vs Claude Code
(plan = inline content) and branches input parsing + output formatting.
Config fixtures live in apps/gemini/ (policy TOML + settings snippet).
Install script gates on ~/.gemini existing so Claude-only users are
unaffected.
For provenance purposes, this commit was AI assisted.
* test(gemini): add manual sandbox script for Gemini CLI integration
Three modes:
- --simulate: pipes BeforeTool JSON to hook, tests approve/deny output
- (default): runs local patched Gemini build
- --nightly: installs Gemini nightly and runs it
Backs up and restores ~/.gemini config on exit.
For provenance purposes, this commit was AI assisted.
* feat(gemini): add slash commands, marketing tab, and docs for Gemini CLI
- Add /plannotator-review and /plannotator-annotate slash commands (.toml)
- Install Gemini slash commands in all three install scripts (sh, ps1, cmd)
- Add Gemini tab to marketing landing page with icon
- Add Gemini CLI to top-level README install section
- Create apps/gemini/README.md with full setup and usage docs
- Remove stale dev:gemini script and regenerate bun.lock
For provenance purposes, this commit was AI assisted.
* fix(gemini): merge hook into existing settings.json instead of printing instructions
When ~/.gemini/settings.json already exists, use node to JSON-merge
the BeforeTool hook config rather than asking the user to do it manually.
Falls back to instructions only if node is unavailable.
For provenance purposes, this commit was AI assisted.
* fix(gemini): handle plan_filename rename and fix scoping bug
Gemini CLI nightly renamed plan_path to plan_filename in exit_plan_mode.
Accept both field names for forward/backward compatibility. Reconstruct
full plan path from transcript_path + session_id + plans/ + filename.
Also hoist planFilename variable out of try block so it's accessible
in the deny output path (was causing ReferenceError).
For provenance purposes, this commit was AI assisted.
* fix(gemini): dim approve button when annotations exist for Gemini CLI
Gemini's hook runner ignores systemMessage on the allow path, so
approve-with-feedback is silently dropped — same limitation as Claude
Code. Extend the existing UI gate to also apply for gemini-cli origin.
For provenance purposes, this commit was AI assisted.
* fix(gemini): add AGENT_CONFIG entry and fix sandbox simulate mode
Register "gemini-cli" in AGENT_CONFIG so the UI shows "Gemini CLI"
with proper badge styling instead of generic "Coding Agent" fallback.
Update sandbox simulate mode to match production input format:
use plan_filename instead of plan_path, include transcript_path,
and simulate the Gemini directory structure for path reconstruction.
For provenance purposes, this commit was AI assisted.
2026-04-02 15:24:10 -07:00
|
|
|
)
|
|
|
|
|
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
if "!SKIP_OPENCODE!"=="1" (
|
|
|
|
|
echo.
|
|
|
|
|
echo OpenCode: integration skipped ^(!SKIP_OPENCODE_SOURCE!^).
|
|
|
|
|
echo No command stubs were written and OpenCode's plugin cache was left alone.
|
|
|
|
|
echo Re-run without the opt-out to install the command stubs.
|
|
|
|
|
)
|
|
|
|
|
|
Add Kiro CLI integration (skills + custom agent, cross-platform installers) (#837)
Universal, auto-detected Kiro CLI support — no flag, no separate installer.
When ~/.kiro exists (or kiro-cli is on PATH), the installer copies Plannotator
skills and a custom agent into ~/.kiro, the same convention used for Codex and
Gemini.
- packages/shared: add the kiro-cli agent origin (badge, prompt runtime,
PLAN_TOOL_NAMES). Origin is cosmetic for Kiro (no dedicated AI provider).
- apps/kiro-cli: 3 origin-baked skills (review/annotate/archive) + an example
custom agent that wires every skill via skill:// resources and a
plannotator-scoped shell tool. setup-goal + visual-explainer install from
apps/skills (no content duplication).
- scripts/install.sh: auto-detect ~/.kiro, sparse-checkout apps/kiro-cli,
install 3 kiro + 2 shared skills + the agent (never clobbering an existing
one); covered by scripts/install.test.ts.
- scripts/install.ps1 + install.cmd: Windows parity mirroring the Codex
pattern. Statically verified only; not yet runtime-tested on Windows.
- docs: installation + Kiro guides, AGENTS.md, env-var reference updated.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-02 14:04:18 -04:00
|
|
|
echo.
|
|
|
|
|
echo ==========================================
|
|
|
|
|
echo KIRO CLI USERS
|
|
|
|
|
echo ==========================================
|
|
|
|
|
echo.
|
|
|
|
|
if "!KIRO_AVAILABLE!"=="1" (
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
if "!SKIP_KIRO!"=="1" (
|
|
|
|
|
echo Kiro was detected, but the integration was skipped ^(!SKIP_KIRO_SOURCE!^).
|
|
|
|
|
echo No files under %USERPROFILE%\.kiro were written or removed. Re-run
|
|
|
|
|
echo without the opt-out to add Kiro skills.
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
) else if "!SKIP_SKILLS!"=="1" (
|
|
|
|
|
echo Kiro was detected, but skills were skipped ^(!SKIP_SKILLS_SOURCE!^), so no
|
|
|
|
|
echo Kiro skills or agent were installed. Re-run without the opt-out to add them.
|
feat(install): Codex opt-out and credential-free attestation verification (#1197)
* feat(install): Codex opt-out and credential-free attestation verification
Implements both asks from #1178 (reported and designed by @astradevkin):
- Per-agent installer opt-outs: --skip-codex / --skip-gemini / --skip-kiro
flags, PLANNOTATOR_SKIP_{CODEX,GEMINI,KIRO}_INSTALL env vars, and
config.json skipInstall.{codex,gemini,kiro} keys, with flag > env >
config precedence mirroring verifyAttestation. Detected-but-skipped is
reported as its own honest state, never conflated with not-detected,
and a skipped agent's home is neither written nor cleaned up.
- Credential-free provenance verification: when --verify-attestation is
active, the Sigstore bundle is fetched from GitHub's public
attestations endpoint (single unauthenticated attempt, no retry) and
verified via gh attestation verify --bundle with the same
--repo/--source-ref/--signer-workflow constraints; gh's authenticated
fetch remains the fallback. TUF trust-root failures are reported as
connectivity, distinct from real provenance failures; every path
stays fail-closed.
Zero behavior change for users who do not opt in: the default install
path is unchanged (verified by sandbox-HOME parity runs against main).
* fix(install): address #1197 review round (H1 retry, M2-M7, lows)
- H1: a failed gh --bundle invocation now retries once through the exact
authenticated path before any classification, so an older gh (unknown
flag) or a corrupt bundle never reports as a provenance failure. Pinned
by a functional stub-gh test; a real failure still fails again on the
retry and aborts.
- M2: the sh config layer extracts the skipInstall object (awk, character
indexed) before matching per-agent keys and honors explicit false as a
veto; cmd now parses the real JSON via PowerShell like ps1. Functional
tests cover the foreign-key collision and explicit-true cases.
- M3: sh names the real cause when the bundle path cannot run (no JSON
extractor vs fetch vs extraction failure) and gains python3 and jq
fallback extractors; docs state the dependency.
- M4: ps1/cmd gate the existing-integration note on plannotator content in
hooks.json and word the skip state as what those platforms actually do
(manual instructions suppressed).
- M5: sh bundle lives inside a private mktemp -d, one rm -rf on every exit,
and a mktemp failure degrades to the fallback instead of aborting.
- M6: README, verifying-your-install, environment-variables, and
installation docs updated for the credential-free path and skip flags.
- M7: ps1/cmd extraction replaced with a byte-exact string scanner (no
ConvertFrom/ConvertTo round trip, immune to DateTime coercion), with
PowerShell-driven unit tests over the captured real attestations
response plus synthetic DateTime and brace-in-string controls.
- Lows: fail-closed abort pinned by a functional test; TUF beats auth in
cmd classification (matches sh/ps1); skipped-state output mentions the
shared ~/.agents/skills; Gemini summary is skip-aware and gains an
honest not-detected state; --skip-opencode do-not-write switch added
(flag, env var, config key) across all three scripts.
* fix(install): review round three (EncodedCommand fetcher, mutation-proof fail-closed test, lows)
- R1: install.cmd's attestation fetcher no longer touches disk. The
%RANDOM%-named %TEMP% .ps1 (predictable-path code execution, the M5
class escalated) is replaced by powershell -NoProfile -EncodedCommand
with a base64(UTF-16LE) payload defined next to its full REM PS:
plaintext; a test decodes the blob and asserts byte equality with the
documented lines plus the security-relevant shape (env-var inputs,
ordinal scan, no JSON round trip, distinct exit codes). Inputs still
travel via env vars. Verified end to end under pwsh: the decoded blob
fetched the real attestations response, wrote 2 bundles, gh verified
the real v0.25.1 binary credential-free (exit 0) and rejected a wrong
binary (exit 1).
- R2: the fail-closed test now asserts the output ENDS with 'Refusing to
install.' - mutation-verified: with the verify-failure exit 1 deleted
the mutant still exits 1 via an incidental mv failure, but the trailing
mv error breaks the endsWith and the test fails; restored, it passes.
- Lows: CI guard test fails loudly when process.env.CI is set and no
pwsh/powershell is on PATH (scanner coverage cannot silently vanish);
scanner IndexOf calls are ordinal in ps1 and the encoded cmd variant;
the awk skipInstall extraction requires optional-whitespace-then-colon-
then-brace after the key (string values can no longer anchor it, with
non-token occurrences skipped, unit-checked against escaped-embedded
payloads); install.cmd comments warn that the fallback-reason literals
inside parenthesized blocks must stay parenthesis-free.
2026-08-04 13:17:27 -07:00
|
|
|
) else (
|
|
|
|
|
echo Kiro skills are installed to %USERPROFILE%\.kiro\skills\
|
|
|
|
|
echo The Plannotator agent is installed to %USERPROFILE%\.kiro\agents\plannotator.json
|
|
|
|
|
echo Launch it: kiro-cli chat --agent plannotator
|
|
|
|
|
)
|
Add Kiro CLI integration (skills + custom agent, cross-platform installers) (#837)
Universal, auto-detected Kiro CLI support — no flag, no separate installer.
When ~/.kiro exists (or kiro-cli is on PATH), the installer copies Plannotator
skills and a custom agent into ~/.kiro, the same convention used for Codex and
Gemini.
- packages/shared: add the kiro-cli agent origin (badge, prompt runtime,
PLAN_TOOL_NAMES). Origin is cosmetic for Kiro (no dedicated AI provider).
- apps/kiro-cli: 3 origin-baked skills (review/annotate/archive) + an example
custom agent that wires every skill via skill:// resources and a
plannotator-scoped shell tool. setup-goal + visual-explainer install from
apps/skills (no content duplication).
- scripts/install.sh: auto-detect ~/.kiro, sparse-checkout apps/kiro-cli,
install 3 kiro + 2 shared skills + the agent (never clobbering an existing
one); covered by scripts/install.test.ts.
- scripts/install.ps1 + install.cmd: Windows parity mirroring the Codex
pattern. Statically verified only; not yet runtime-tested on Windows.
- docs: installation + Kiro guides, AGENTS.md, env-var reference updated.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-02 14:04:18 -04:00
|
|
|
) else (
|
|
|
|
|
echo Kiro was not detected. After installing Kiro, rerun this installer to add Kiro skills.
|
|
|
|
|
)
|
|
|
|
|
|
2025-12-28 14:44:54 -08:00
|
|
|
echo.
|
2025-12-28 16:16:30 -08:00
|
|
|
echo Test the install:
|
|
|
|
|
echo echo {"tool_input":{"plan":"# Test Plan\\n\\nHello world"}} ^| plannotator
|
|
|
|
|
echo.
|
|
|
|
|
echo Then install the Claude Code plugin:
|
|
|
|
|
echo /plugin marketplace add backnotprop/plannotator
|
|
|
|
|
echo /plugin install plannotator@plannotator
|
2025-12-28 14:44:54 -08:00
|
|
|
echo.
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
echo Upgrading from an older version? Also run /plugin marketplace update
|
|
|
|
|
echo so the plugin drops its old plannotator:* command entries.
|
|
|
|
|
echo.
|
fix(install): repair the skills checkout guard, add --skip-skills (#1201)
* fix(install): make a failed skills checkout stop reporting success
The skills/commands checkout runs in a subshell written as
`( set -e; ... ) || checkout_failed=1`. POSIX ignores `set -e` for every
command of an AND-OR list except the last, and bash 3.2.57 (what
`curl | bash` gets on macOS), bash 5.3, dash, zsh and ksh all carry that
suppression into the subshell. The `set -e` was inert.
A failed clone therefore ran the whole block anyway, the subshell exited
with the status of its trailing `if` (0), `checkout_failed` stayed 0, and
the installer printed "YOU'RE ALL SET!" with no skills installed. It also
blamed the wrong thing, printing "Tag vX.Y.Z predates the per-agent skill
layout" when the real cause was a failed clone.
Drop the inert `set -e` and guard the four fetch steps with explicit
`|| exit 1`. Everything after the checkout stays best-effort, matching
install.cmd, which only checks git clone and lets every xcopy run
unchecked. A local cp/mkdir/rm failure must not surface as the
"network or git error" message.
Verified on bash 3.2.57 in a sandboxed HOME: the failure case now exits 1
with the fetch error and no success banner, and original vs patched
success runs produce byte-identical trees (74 paths, 35 files) and
identical logs.
* feat(install): add --skip-skills opt-out
The skills and slash commands come from a sparse `git clone` of the release
tag. There was no way to decline that fetch short of --minimal, which also
drops the sem sidecar, the agent-terminal runtime, the hooks, and every
per-agent config. Anything that installs a tag github.com cannot serve had
no option at all.
Add --skip-skills to all three installers, following the existing
--skip-codex / --skip-gemini / --skip-kiro / --skip-opencode family: CLI
flag (-SkipSkills in PowerShell), PLANNOTATOR_SKIP_SKILLS_INSTALL env var,
skipInstall.skills config key, resolved flag > env > config. It is not a
per-agent switch; it covers every scope the checkout writes (Claude,
~/.agents, OpenCode, Gemini, Kiro), the extras, and the skill-scope cleanup
sweeps. Skip means do-not-write: nothing already installed is replaced or
removed, and git stops being a hard requirement. The run reports
"Skills: skipped (<source>)" and the closing banner no longer claims the
/plannotator-* commands are ready, which is the same false-success the
checkout guard exists to prevent.
Use it in the install-script-smoke job. That job installs a synthetic
v9.9.9: the fake curl serves the freshly built binary for any URL, but the
skills clone goes to real github.com, where the tag does not and cannot
exist. That clone has always failed; it only went unnoticed while the
broken guard let the installer exit 0 anyway. The job asserts Codex hook
config, not skills, so it opts out rather than ignoring a real error. Both
run_installer call sites go through the one function definition.
Verified in an env -i sandbox on bash 3.2.57 (what `curl | bash` gets on
macOS) with a fake curl and a local stand-in remote. Flag, env var, and
config each skip and name their own source; flag beats env=0; env=0 beats
config true; an explicit "skills": false stays a veto. Without the flag,
pre-change and post-change runs produce byte-identical trees (39 entries)
and identical logs. A bad clone URL without the flag still exits 1 with the
fetch error and no success banner. A --skip-skills re-run over an existing
install leaves all 12 skill and command files byte-identical. The CI step
was reproduced locally: both run_installer calls exit 0 and every Codex
assertion still passes.
* test(install): cover --skip-skills and repoint the pinned source strings
scripts/install.test.ts asserts against exact install-script source text, so
six assertions broke when --skip-skills landed. Each is repointed at the new
string with its intent preserved, not weakened:
- The "hook/config writing happens before the git hard-fail" ordering test
keeps proving the ordering; it just matches the gate's new conditional
form. git being a hard requirement is now a narrower invariant (it applies
only when the checkout actually runs), so that is asserted separately
rather than dropped.
- The skipInstall walk assertions follow codex/gemini/kiro/opencode gaining
a skills entry, in install.sh's `for _agent` loop and install.cmd's
PowerShell key list.
- The three "never remove" sweep assertions follow the Codex stale-skill
cleanup gaining its skills-opt-out arm, in all three installers.
Add nine tests covering --skip-skills itself in the same style as the
per-agent family: flag/switch parsing, PLANNOTATOR_SKIP_SKILLS_INSTALL,
skipInstall.skills, and flag > env > config precedence by textual layering,
for each installer. Each installer also gets a test that the opt-out bails
before the clone and leaves the checkout guard intact (#1201's fix must keep
failing a real fetch error), and one that the run reports honestly, never
prints the "commands are ready" banner over an empty skills dir, and
suspends the extras, the model-invocation rewrite, and the stale-stub sweeps
rather than applying them partially.
bun test scripts/: 116 pass, 6 skip, 0 fail. Full bun test: 2884 pass,
234 skip, 0 fail. bun run typecheck clean.
2026-08-04 21:49:49 -07:00
|
|
|
REM Never claim the /plannotator-* skills are ready when nothing was installed -
|
|
|
|
|
REM that false banner is exactly what the skills-checkout guard exists to prevent.
|
|
|
|
|
if "!SKIP_SKILLS!"=="1" (
|
|
|
|
|
echo Skills were skipped ^(!SKIP_SKILLS_SOURCE!^), so the /plannotator-review,
|
|
|
|
|
echo /plannotator-annotate, and /plannotator-last skills are NOT installed.
|
|
|
|
|
echo Re-run the installer without the opt-out to add them.
|
|
|
|
|
) else (
|
|
|
|
|
echo The /plannotator-review, /plannotator-annotate, and /plannotator-last skills are ready to use!
|
|
|
|
|
)
|
|
|
|
|
if "!SKIP_SKILLS!"=="0" if not "!EXTRAS_CHOICE!"=="yes" (
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
echo.
|
|
|
|
|
echo Optional skills ^(compound planning, setup-goal, visual explainer^):
|
2026-07-20 21:05:10 +02:00
|
|
|
echo npx skills add backnotprop/plannotator/apps/skills/extra --global
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
)
|
2026-03-05 19:17:47 -08:00
|
|
|
|
|
|
|
|
REM Warn if plannotator is configured in both settings.json hooks AND the plugin (causes double execution)
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Only warn when the plugin is installed - manual-only users won't have overlap
|
2026-03-05 19:17:47 -08:00
|
|
|
if defined CLAUDE_CONFIG_DIR (
|
|
|
|
|
set "CLAUDE_SETTINGS=%CLAUDE_CONFIG_DIR%\settings.json"
|
|
|
|
|
) else (
|
|
|
|
|
set "CLAUDE_SETTINGS=%USERPROFILE%\.claude\settings.json"
|
|
|
|
|
)
|
|
|
|
|
if exist "!PLUGIN_HOOKS!" if exist "!CLAUDE_SETTINGS!" (
|
|
|
|
|
findstr /r /c:"\"command\".*plannotator" "!CLAUDE_SETTINGS!" >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 (
|
|
|
|
|
echo.
|
|
|
|
|
echo WARNING: DUPLICATE HOOK DETECTED
|
|
|
|
|
echo.
|
|
|
|
|
echo plannotator was found in your settings.json hooks:
|
|
|
|
|
echo !CLAUDE_SETTINGS!
|
|
|
|
|
echo.
|
|
|
|
|
echo This will cause plannotator to run TWICE on each plan review.
|
|
|
|
|
echo Remove the plannotator hook from settings.json and rely on the
|
|
|
|
|
echo plugin instead ^(installed automatically via marketplace^).
|
|
|
|
|
echo.
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
2026-01-12 19:36:09 -08:00
|
|
|
echo.
|
2025-12-28 14:44:54 -08:00
|
|
|
exit /b 0
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
|
feat(install): add --minimal binary-only install mode (#989)
* feat(install): add --minimal binary-only install mode
install.sh installs the plannotator binary and then writes a large amount
of extra state: the sem sidecar, the agent-terminal runtime, and per-agent
skills, hooks, slash commands, and config for Claude, Codex, OpenCode,
Gemini, and Kiro. There is no way to get just the binary — even the
--no-extras path still writes ~/.claude skills and OpenCode commands.
Add a --minimal flag (aliased --binary-only) plus a PLANNOTATOR_MINIMAL
env var for `curl | bash` runs. Minimal mode installs only the binary to
~/.local/bin, prints PATH advice, and exits before any sidecar download,
agent integration, skill checkout, config write, cache clear, or cleanup
migration. Precedence: flag > env var > default (off).
The PATH-advice block is extracted into print_path_advice() so both the
minimal early exit and the normal flow reuse it.
Closes #977
* feat(install): mirror minimal mode to ps1/cmd, add --no-minimal, docs
Extend the binary-only install mode to full cross-installer parity and
address the Copilot review on #989.
install.sh:
- Add --no-minimal (MINIMAL_FLAG=0) so a CLI flag can override
PLANNOTATOR_MINIMAL=1 in both directions; the -1/0/1 comment is now
accurate. --minimal/--no-minimal are mutually exclusive.
- Document the --binary-only alias and soften the absolute "nothing
written outside ..." wording to "no persistent state" (minimal mode
still uses a temp download file and may read the config dir).
install.ps1 / install.cmd:
- Add -Minimal (alias BinaryOnly)/-NoMinimal and --minimal/--binary-only/
--no-minimal with PLANNOTATOR_MINIMAL resolution, mirroring install.sh.
- Extract PATH advice into Show-PathAdvice / :PrintPathAdvice and reuse it
in both the minimal early exit and the normal flow.
- Early-exit after the binary is placed, before the sidecar/agent/skill/
config work.
Tests: add minimal-mode assertions to the install.ps1 and install.cmd
describe blocks plus a shared-behavior test asserting all three installers
support it; extend the sh tests for --no-minimal.
Docs: document --minimal / PLANNOTATOR_MINIMAL in the installation guide
(noting minimal mode needs no git) and add PLANNOTATOR_MINIMAL (and backfill
PLANNOTATOR_SKIP_SEM_INSTALL) to the env-var registries.
* docs(install): correct minimal-mode PATH wording (ps1 persists PATH)
The PowerShell installer's minimal path calls Show-PathAdvice, which
persistently writes the user PATH — so "no persistent state is written
outside $installDir" overpromised. Reword the install.ps1 comment and the
installation docs to describe what minimal mode skips (sidecar, agent
runtime, per-agent integrations) and note the binary + PATH entry are still
added on Windows. Addresses the second Copilot review on #989.
* fix(install.cmd): use delayed expansion for PLANNOTATOR_MINIMAL checks
The three new env-var checks used immediate %VAR% expansion; under
setlocal enabledelayedexpansion a poisoned value re-exposes cmd
metacharacters at parse time (command injection). Switch to the !VAR!
idiom the script already uses for every other untrusted env var (e.g.
the PLANNOTATOR_VERIFY_ATTESTATION block).
---------
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
2026-07-07 00:43:42 +02:00
|
|
|
REM ======================================================================
|
|
|
|
|
REM Print the PATH-setup hint if INSTALL_DIR isn't already on PATH. Called by
|
|
|
|
|
REM both the --minimal early exit and the normal flow (mirrors install.sh's
|
|
|
|
|
REM print_path_advice).
|
|
|
|
|
REM ======================================================================
|
|
|
|
|
:PrintPathAdvice
|
|
|
|
|
echo !PATH! | findstr /i /c:"!INSTALL_DIR!" >nul
|
|
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
echo.
|
|
|
|
|
echo !INSTALL_DIR! is not in your PATH.
|
|
|
|
|
echo.
|
|
|
|
|
echo Add it permanently with:
|
|
|
|
|
echo.
|
|
|
|
|
echo setx PATH "%%PATH%%;!INSTALL_DIR!"
|
|
|
|
|
echo.
|
|
|
|
|
echo Or add it for this session only:
|
|
|
|
|
echo.
|
|
|
|
|
echo set PATH=%%PATH%%;!INSTALL_DIR!
|
|
|
|
|
)
|
2026-08-01 10:26:42 -07:00
|
|
|
echo.
|
|
|
|
|
echo To uninstall later: plannotator uninstall
|
feat(install): add --minimal binary-only install mode (#989)
* feat(install): add --minimal binary-only install mode
install.sh installs the plannotator binary and then writes a large amount
of extra state: the sem sidecar, the agent-terminal runtime, and per-agent
skills, hooks, slash commands, and config for Claude, Codex, OpenCode,
Gemini, and Kiro. There is no way to get just the binary — even the
--no-extras path still writes ~/.claude skills and OpenCode commands.
Add a --minimal flag (aliased --binary-only) plus a PLANNOTATOR_MINIMAL
env var for `curl | bash` runs. Minimal mode installs only the binary to
~/.local/bin, prints PATH advice, and exits before any sidecar download,
agent integration, skill checkout, config write, cache clear, or cleanup
migration. Precedence: flag > env var > default (off).
The PATH-advice block is extracted into print_path_advice() so both the
minimal early exit and the normal flow reuse it.
Closes #977
* feat(install): mirror minimal mode to ps1/cmd, add --no-minimal, docs
Extend the binary-only install mode to full cross-installer parity and
address the Copilot review on #989.
install.sh:
- Add --no-minimal (MINIMAL_FLAG=0) so a CLI flag can override
PLANNOTATOR_MINIMAL=1 in both directions; the -1/0/1 comment is now
accurate. --minimal/--no-minimal are mutually exclusive.
- Document the --binary-only alias and soften the absolute "nothing
written outside ..." wording to "no persistent state" (minimal mode
still uses a temp download file and may read the config dir).
install.ps1 / install.cmd:
- Add -Minimal (alias BinaryOnly)/-NoMinimal and --minimal/--binary-only/
--no-minimal with PLANNOTATOR_MINIMAL resolution, mirroring install.sh.
- Extract PATH advice into Show-PathAdvice / :PrintPathAdvice and reuse it
in both the minimal early exit and the normal flow.
- Early-exit after the binary is placed, before the sidecar/agent/skill/
config work.
Tests: add minimal-mode assertions to the install.ps1 and install.cmd
describe blocks plus a shared-behavior test asserting all three installers
support it; extend the sh tests for --no-minimal.
Docs: document --minimal / PLANNOTATOR_MINIMAL in the installation guide
(noting minimal mode needs no git) and add PLANNOTATOR_MINIMAL (and backfill
PLANNOTATOR_SKIP_SEM_INSTALL) to the env-var registries.
* docs(install): correct minimal-mode PATH wording (ps1 persists PATH)
The PowerShell installer's minimal path calls Show-PathAdvice, which
persistently writes the user PATH — so "no persistent state is written
outside $installDir" overpromised. Reword the install.ps1 comment and the
installation docs to describe what minimal mode skips (sidecar, agent
runtime, per-agent integrations) and note the binary + PATH entry are still
added on Windows. Addresses the second Copilot review on #989.
* fix(install.cmd): use delayed expansion for PLANNOTATOR_MINIMAL checks
The three new env-var checks used immediate %VAR% expansion; under
setlocal enabledelayedexpansion a poisoned value re-exposes cmd
metacharacters at parse time (command injection). Switch to the !VAR!
idiom the script already uses for every other untrusted env var (e.g.
the PLANNOTATOR_VERIFY_ATTESTATION block).
---------
Co-authored-by: Michael Ramos <mdramos8@gmail.com>
2026-07-07 00:43:42 +02:00
|
|
|
goto :eof
|
|
|
|
|
|
2026-06-19 09:04:15 -07:00
|
|
|
REM ======================================================================
|
|
|
|
|
REM Optional annotate agent terminal runtime install. Non-fatal: Plannotator
|
|
|
|
|
REM remains installed if Node/npm or npm install is unavailable.
|
|
|
|
|
REM ======================================================================
|
|
|
|
|
:InstallAgentTerminalRuntime
|
|
|
|
|
if /i "!PLANNOTATOR_SKIP_AGENT_TERMINAL_INSTALL!"=="1" (
|
|
|
|
|
echo Skipping agent terminal runtime install ^(PLANNOTATOR_SKIP_AGENT_TERMINAL_INSTALL is set^)
|
|
|
|
|
goto :eof
|
|
|
|
|
)
|
|
|
|
|
if /i "!PLANNOTATOR_SKIP_AGENT_TERMINAL_INSTALL!"=="true" (
|
|
|
|
|
echo Skipping agent terminal runtime install ^(PLANNOTATOR_SKIP_AGENT_TERMINAL_INSTALL is set^)
|
|
|
|
|
goto :eof
|
|
|
|
|
)
|
|
|
|
|
if /i "!PLANNOTATOR_SKIP_AGENT_TERMINAL_INSTALL!"=="yes" (
|
|
|
|
|
echo Skipping agent terminal runtime install ^(PLANNOTATOR_SKIP_AGENT_TERMINAL_INSTALL is set^)
|
|
|
|
|
goto :eof
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
"!INSTALL_PATH!" install-runtime agent-terminal
|
|
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
echo Skipping agent terminal runtime install ^(plannotator install-runtime failed^)
|
|
|
|
|
)
|
|
|
|
|
goto :eof
|
|
|
|
|
|
feat(review): add semantic diff overview (#871)
* feat(review): add semantic diff overview
* fix(review): address semantic diff review findings
* fix(review): harden semantic diff fallback
* fix(review): avoid repo-local sem execution
* fix(review): normalize semantic diff cwd
* test(review): cover semantic diff local cwd
* fix(gitlab): fetch raw MR diffs
* fix(review): harden sem path resolution
* docs(review): add semantic diff handoff
* feat(review): semantic diff cards, header sem badges, jump-to-line
- Restyle the semantic panel as real bordered cards (shadcn surface) instead
of ASCII box-drawing; centered column, grid-aligned entity rows.
- Hide orphan (module-level) changes from the rows, matching sem's default;
the count still surfaces in the summary line.
- Add a 'sem · N' hover popover to each diff file header showing that file's
semantic changes, reusing the same row component as the panel.
- Clicking an entity (panel or popover) scrolls the diff to the lines via
pierre's [data-selected-line]; centers only when off-screen so manual
drag-selection isn't disturbed.
- Extract shared rows/helpers into semanticDiffShared; share one cached
/api/semantic-diff fetch across header badges.
* feat(review): land on All files by default
Semantic diff stays available via the file-tree nav entry and header badges,
but it's no longer the initial landing view.
* chore(review): drop dead change-symbol entries, log badge fetch failures
- Remove unreachable 'moved'/'renamed' entries from the changeSymbols table
(getChangeSymbol early-returns for those before the lookup).
- Log a console.error once per patch when the file-header badge's semantic
diff fetch fails or returns a non-ok status, so a systemic failure leaves a
trace instead of every badge silently showing nothing.
* feat(review): flatten semantic diff panel into grouped list
- Dissolve the per-file bordered cards into flat sections: the file path is now
a quiet underlined header (single hairline) with entity rows flush beneath,
hierarchy from whitespace + hover tint instead of boxes.
- Split the path into muted directory + emphasized filename for faster scanning.
- Nudge the add/remove glyphs (⊕/⊖) ~15% larger, line-height pinned so rows
don't grow; modified/rename/reorder glyphs unchanged.
2026-06-08 22:23:54 -07:00
|
|
|
REM ======================================================================
|
|
|
|
|
REM Optional semantic diff sidecar install. Non-fatal: Plannotator remains
|
|
|
|
|
REM installed if sem download, checksum, or extraction fails.
|
|
|
|
|
REM ======================================================================
|
|
|
|
|
:InstallSemSidecar
|
|
|
|
|
if /i "!PLANNOTATOR_SKIP_SEM_INSTALL!"=="1" (
|
|
|
|
|
echo Skipping semantic diff sidecar install ^(PLANNOTATOR_SKIP_SEM_INSTALL is set^)
|
|
|
|
|
goto :eof
|
|
|
|
|
)
|
|
|
|
|
if /i "!PLANNOTATOR_SKIP_SEM_INSTALL!"=="true" (
|
|
|
|
|
echo Skipping semantic diff sidecar install ^(PLANNOTATOR_SKIP_SEM_INSTALL is set^)
|
|
|
|
|
goto :eof
|
|
|
|
|
)
|
|
|
|
|
if /i "!PLANNOTATOR_SKIP_SEM_INSTALL!"=="yes" (
|
|
|
|
|
echo Skipping semantic diff sidecar install ^(PLANNOTATOR_SKIP_SEM_INSTALL is set^)
|
|
|
|
|
goto :eof
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
set "SEM_ASSET="
|
|
|
|
|
if /i "!PLATFORM!"=="win32-x64" set "SEM_ASSET=sem-windows-x86_64.zip"
|
|
|
|
|
if not defined SEM_ASSET (
|
|
|
|
|
echo Skipping semantic diff sidecar install ^(sem does not publish !PLATFORM!^)
|
|
|
|
|
goto :eof
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
set "SEM_DIR=!_CONFIG_DIR!\vendor\sem\!SEM_VERSION!"
|
|
|
|
|
set "SEM_PATH=!SEM_DIR!\sem.exe"
|
|
|
|
|
if exist "!SEM_PATH!" (
|
|
|
|
|
"!SEM_PATH!" --version 2>nul | findstr /r /c:"^sem " >nul 2>&1
|
|
|
|
|
if !ERRORLEVEL! equ 0 (
|
|
|
|
|
echo Semantic diff sidecar already installed at !SEM_PATH!
|
|
|
|
|
goto :eof
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
set "SEM_BASE_URL=https://github.com/!SEM_REPO!/releases/download/!SEM_VERSION!"
|
|
|
|
|
set "SEM_ARCHIVE=%TEMP%\plannotator-sem-%RANDOM%.zip"
|
|
|
|
|
set "SEM_CHECKSUMS=%TEMP%\plannotator-sem-checksums-%RANDOM%.txt"
|
|
|
|
|
set "SEM_EXTRACT=%TEMP%\plannotator-sem-%RANDOM%"
|
|
|
|
|
mkdir "!SEM_EXTRACT!" >nul 2>&1
|
|
|
|
|
|
Plan-look chooser + 0.20.0 release dialog (with GitLab / sem / install fixes) (#879)
* feat(plan): default to the grid look + look-and-feel image chooser
- Flip gridEnabled default back to true (classic grid / floating-card look),
reverting #863's flat-by-default so existing users without an explicit
choice return to the grid view they're used to.
- Rewrite the look-and-feel announcement into a two-image chooser: Grid
(classic, now the default) vs Clean (the new flat look), each a clickable
screenshot that hover-zooms to preview — mirroring the code-review
DiffTypeSetupDialog pattern.
- Bump the announcement version (1 -> 2) so existing users are re-offered the
choice once.
- Add look-grid.png / look-flat.png preview assets (resized app screenshots).
* fix(review): restore GitLab /diffs fallback for MR review
#871's pr-gitlab refactor moved to the raw_diffs endpoint and deleted the
paginated /diffs path, hard-breaking MR review on self-hosted GitLab too old to
expose raw_diffs (opaque "Failed to fetch MR diff") and silently rendering zero
files when raw_diffs returns empty for oversized MRs.
Keep raw_diffs as the primary path (it preserves binary markers + collapsed
content), but fall back to the restored paginated /diffs + reconstructPatch when
raw_diffs fails or is empty, and throw a clear "diff is empty / too large" error
if both come back empty. Restores parsePaginatedArray / reconstructPatch and
adds tests for the fallback paths.
* fix(install): bound the optional sem sidecar download
The semantic-diff 'sem' download (#871) ran curl / Invoke-WebRequest with no
timeout. The sidecar installs after plannotator itself, so a slow or hung fetch
could wedge an otherwise-complete install. Add --connect-timeout 10
--max-time 120/60 (sh, cmd) and -TimeoutSec 120/60 (ps1) so it times out and
skips gracefully, and document the PLANNOTATOR_SKIP_SEM_INSTALL opt-out in the
installer help.
* chore(install): remove the Glimpse install option from the installers
The installers offered to `npm install -g glimpseui` (a wizard prompt +
--glimpse/--no-glimpse flags + saved pref). Drop all of it across install.sh,
install.ps1, and install.cmd: flags, usage text, the wizard question, the
glimpse_present detection, the saved-pref read/write, the persistence clauses,
and the install block. The guided wizard is now two questions (extras,
model-invocable).
Runtime Glimpse support is unchanged: the app still opens in the native window
if glimpseui is on PATH (packages/server/browser.ts), still gated by
PLANNOTATOR_GLIMPSE. Updated install.test.ts (asserts the installers are
glimpse-free) and the installation docs.
* feat(plan): 0.20.0 release announcement dialog
Turn the first-run look chooser into a two-page 0.20.0 announcement.
- Page 1: header with a "Full release notes" link, a four-up feature
grid (fresh look, semantic review, multi-repo review, leaner install),
and the grid/clean plan-look chooser.
- Page 2: "Workspaces are coming" teaser with the waitlist image + link.
- Footer actions grouped bottom-right on both pages (shimmering
"Workspaces are coming" teaser via TextShimmer + the primary action)
so focus stays in one corner across the page turn.
- Reshoot the grid/clean chooser screenshots on a clean prose plan and
add the workspaces teaser image.
* feat(plan): add full-page HTML feature card, lead with leaner install
Add a fifth what's-new card for --render-html (annotate HTML reports and
explainers rendered full-screen) and move Leaner install to the front of
the grid.
2026-06-09 09:45:20 -07:00
|
|
|
REM Bounded so a slow/hung download of this optional sidecar can't wedge an
|
|
|
|
|
REM install where plannotator already landed. Opt out with PLANNOTATOR_SKIP_SEM_INSTALL=1.
|
|
|
|
|
curl -fsSL --connect-timeout 10 --max-time 120 "!SEM_BASE_URL!/!SEM_ASSET!" -o "!SEM_ARCHIVE!"
|
feat(review): add semantic diff overview (#871)
* feat(review): add semantic diff overview
* fix(review): address semantic diff review findings
* fix(review): harden semantic diff fallback
* fix(review): avoid repo-local sem execution
* fix(review): normalize semantic diff cwd
* test(review): cover semantic diff local cwd
* fix(gitlab): fetch raw MR diffs
* fix(review): harden sem path resolution
* docs(review): add semantic diff handoff
* feat(review): semantic diff cards, header sem badges, jump-to-line
- Restyle the semantic panel as real bordered cards (shadcn surface) instead
of ASCII box-drawing; centered column, grid-aligned entity rows.
- Hide orphan (module-level) changes from the rows, matching sem's default;
the count still surfaces in the summary line.
- Add a 'sem · N' hover popover to each diff file header showing that file's
semantic changes, reusing the same row component as the panel.
- Clicking an entity (panel or popover) scrolls the diff to the lines via
pierre's [data-selected-line]; centers only when off-screen so manual
drag-selection isn't disturbed.
- Extract shared rows/helpers into semanticDiffShared; share one cached
/api/semantic-diff fetch across header badges.
* feat(review): land on All files by default
Semantic diff stays available via the file-tree nav entry and header badges,
but it's no longer the initial landing view.
* chore(review): drop dead change-symbol entries, log badge fetch failures
- Remove unreachable 'moved'/'renamed' entries from the changeSymbols table
(getChangeSymbol early-returns for those before the lookup).
- Log a console.error once per patch when the file-header badge's semantic
diff fetch fails or returns a non-ok status, so a systemic failure leaves a
trace instead of every badge silently showing nothing.
* feat(review): flatten semantic diff panel into grouped list
- Dissolve the per-file bordered cards into flat sections: the file path is now
a quiet underlined header (single hairline) with entity rows flush beneath,
hierarchy from whitespace + hover tint instead of boxes.
- Split the path into muted directory + emphasized filename for faster scanning.
- Nudge the add/remove glyphs (⊕/⊖) ~15% larger, line-height pinned so rows
don't grow; modified/rename/reorder glyphs unchanged.
2026-06-08 22:23:54 -07:00
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
echo Skipping semantic diff sidecar install ^(download failed^)
|
|
|
|
|
goto :sem_cleanup
|
|
|
|
|
)
|
|
|
|
|
|
Plan-look chooser + 0.20.0 release dialog (with GitLab / sem / install fixes) (#879)
* feat(plan): default to the grid look + look-and-feel image chooser
- Flip gridEnabled default back to true (classic grid / floating-card look),
reverting #863's flat-by-default so existing users without an explicit
choice return to the grid view they're used to.
- Rewrite the look-and-feel announcement into a two-image chooser: Grid
(classic, now the default) vs Clean (the new flat look), each a clickable
screenshot that hover-zooms to preview — mirroring the code-review
DiffTypeSetupDialog pattern.
- Bump the announcement version (1 -> 2) so existing users are re-offered the
choice once.
- Add look-grid.png / look-flat.png preview assets (resized app screenshots).
* fix(review): restore GitLab /diffs fallback for MR review
#871's pr-gitlab refactor moved to the raw_diffs endpoint and deleted the
paginated /diffs path, hard-breaking MR review on self-hosted GitLab too old to
expose raw_diffs (opaque "Failed to fetch MR diff") and silently rendering zero
files when raw_diffs returns empty for oversized MRs.
Keep raw_diffs as the primary path (it preserves binary markers + collapsed
content), but fall back to the restored paginated /diffs + reconstructPatch when
raw_diffs fails or is empty, and throw a clear "diff is empty / too large" error
if both come back empty. Restores parsePaginatedArray / reconstructPatch and
adds tests for the fallback paths.
* fix(install): bound the optional sem sidecar download
The semantic-diff 'sem' download (#871) ran curl / Invoke-WebRequest with no
timeout. The sidecar installs after plannotator itself, so a slow or hung fetch
could wedge an otherwise-complete install. Add --connect-timeout 10
--max-time 120/60 (sh, cmd) and -TimeoutSec 120/60 (ps1) so it times out and
skips gracefully, and document the PLANNOTATOR_SKIP_SEM_INSTALL opt-out in the
installer help.
* chore(install): remove the Glimpse install option from the installers
The installers offered to `npm install -g glimpseui` (a wizard prompt +
--glimpse/--no-glimpse flags + saved pref). Drop all of it across install.sh,
install.ps1, and install.cmd: flags, usage text, the wizard question, the
glimpse_present detection, the saved-pref read/write, the persistence clauses,
and the install block. The guided wizard is now two questions (extras,
model-invocable).
Runtime Glimpse support is unchanged: the app still opens in the native window
if glimpseui is on PATH (packages/server/browser.ts), still gated by
PLANNOTATOR_GLIMPSE. Updated install.test.ts (asserts the installers are
glimpse-free) and the installation docs.
* feat(plan): 0.20.0 release announcement dialog
Turn the first-run look chooser into a two-page 0.20.0 announcement.
- Page 1: header with a "Full release notes" link, a four-up feature
grid (fresh look, semantic review, multi-repo review, leaner install),
and the grid/clean plan-look chooser.
- Page 2: "Workspaces are coming" teaser with the waitlist image + link.
- Footer actions grouped bottom-right on both pages (shimmering
"Workspaces are coming" teaser via TextShimmer + the primary action)
so focus stays in one corner across the page turn.
- Reshoot the grid/clean chooser screenshots on a clean prose plan and
add the workspaces teaser image.
* feat(plan): add full-page HTML feature card, lead with leaner install
Add a fifth what's-new card for --render-html (annotate HTML reports and
explainers rendered full-screen) and move Leaner install to the front of
the grid.
2026-06-09 09:45:20 -07:00
|
|
|
curl -fsSL --connect-timeout 10 --max-time 60 "!SEM_BASE_URL!/checksums.txt" -o "!SEM_CHECKSUMS!"
|
feat(review): add semantic diff overview (#871)
* feat(review): add semantic diff overview
* fix(review): address semantic diff review findings
* fix(review): harden semantic diff fallback
* fix(review): avoid repo-local sem execution
* fix(review): normalize semantic diff cwd
* test(review): cover semantic diff local cwd
* fix(gitlab): fetch raw MR diffs
* fix(review): harden sem path resolution
* docs(review): add semantic diff handoff
* feat(review): semantic diff cards, header sem badges, jump-to-line
- Restyle the semantic panel as real bordered cards (shadcn surface) instead
of ASCII box-drawing; centered column, grid-aligned entity rows.
- Hide orphan (module-level) changes from the rows, matching sem's default;
the count still surfaces in the summary line.
- Add a 'sem · N' hover popover to each diff file header showing that file's
semantic changes, reusing the same row component as the panel.
- Clicking an entity (panel or popover) scrolls the diff to the lines via
pierre's [data-selected-line]; centers only when off-screen so manual
drag-selection isn't disturbed.
- Extract shared rows/helpers into semanticDiffShared; share one cached
/api/semantic-diff fetch across header badges.
* feat(review): land on All files by default
Semantic diff stays available via the file-tree nav entry and header badges,
but it's no longer the initial landing view.
* chore(review): drop dead change-symbol entries, log badge fetch failures
- Remove unreachable 'moved'/'renamed' entries from the changeSymbols table
(getChangeSymbol early-returns for those before the lookup).
- Log a console.error once per patch when the file-header badge's semantic
diff fetch fails or returns a non-ok status, so a systemic failure leaves a
trace instead of every badge silently showing nothing.
* feat(review): flatten semantic diff panel into grouped list
- Dissolve the per-file bordered cards into flat sections: the file path is now
a quiet underlined header (single hairline) with entity rows flush beneath,
hierarchy from whitespace + hover tint instead of boxes.
- Split the path into muted directory + emphasized filename for faster scanning.
- Nudge the add/remove glyphs (⊕/⊖) ~15% larger, line-height pinned so rows
don't grow; modified/rename/reorder glyphs unchanged.
2026-06-08 22:23:54 -07:00
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
echo Skipping semantic diff sidecar install ^(checksum download failed^)
|
|
|
|
|
goto :sem_cleanup
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
set "EXPECTED_SEM_CHECKSUM="
|
|
|
|
|
for /f "usebackq tokens=1,2" %%i in ("!SEM_CHECKSUMS!") do (
|
|
|
|
|
if "%%j"=="!SEM_ASSET!" set "EXPECTED_SEM_CHECKSUM=%%i"
|
|
|
|
|
)
|
|
|
|
|
if not defined EXPECTED_SEM_CHECKSUM (
|
|
|
|
|
echo Skipping semantic diff sidecar install ^(checksum missing for !SEM_ASSET!^)
|
|
|
|
|
goto :sem_cleanup
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
set "ACTUAL_SEM_CHECKSUM="
|
|
|
|
|
for /f "skip=1 tokens=*" %%i in ('certutil -hashfile "!SEM_ARCHIVE!" SHA256') do (
|
|
|
|
|
if not defined ACTUAL_SEM_CHECKSUM (
|
|
|
|
|
set "ACTUAL_SEM_CHECKSUM=%%i"
|
|
|
|
|
set "ACTUAL_SEM_CHECKSUM=!ACTUAL_SEM_CHECKSUM: =!"
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
if /i "!ACTUAL_SEM_CHECKSUM!" neq "!EXPECTED_SEM_CHECKSUM!" (
|
|
|
|
|
echo Skipping semantic diff sidecar install ^(checksum mismatch^)
|
|
|
|
|
goto :sem_cleanup
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
powershell -NoProfile -ExecutionPolicy Bypass -Command "Expand-Archive -Force -Path $env:SEM_ARCHIVE -DestinationPath $env:SEM_EXTRACT"
|
|
|
|
|
if !ERRORLEVEL! neq 0 (
|
|
|
|
|
echo Skipping semantic diff sidecar install ^(extract failed^)
|
|
|
|
|
goto :sem_cleanup
|
|
|
|
|
)
|
|
|
|
|
set "EXTRACTED_SEM="
|
|
|
|
|
for /f "usebackq delims=" %%i in (`powershell -NoProfile -ExecutionPolicy Bypass -Command "Get-ChildItem -Path $env:SEM_EXTRACT -Filter sem.exe -Recurse -File | Select-Object -First 1 -ExpandProperty FullName"`) do (
|
|
|
|
|
set "EXTRACTED_SEM=%%i"
|
|
|
|
|
)
|
|
|
|
|
if not defined EXTRACTED_SEM (
|
|
|
|
|
echo Skipping semantic diff sidecar install ^(binary missing from archive^)
|
|
|
|
|
goto :sem_cleanup
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
if not exist "!SEM_DIR!" mkdir "!SEM_DIR!"
|
|
|
|
|
copy /y "!EXTRACTED_SEM!" "!SEM_PATH!" >nul
|
|
|
|
|
if !ERRORLEVEL! equ 0 (
|
|
|
|
|
echo Semantic diff sidecar installed to !SEM_PATH!
|
|
|
|
|
) else (
|
|
|
|
|
echo Skipping semantic diff sidecar install ^(copy failed^)
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
:sem_cleanup
|
|
|
|
|
if exist "!SEM_ARCHIVE!" del "!SEM_ARCHIVE!"
|
|
|
|
|
if exist "!SEM_CHECKSUMS!" del "!SEM_CHECKSUMS!"
|
|
|
|
|
if exist "!SEM_EXTRACT!" rmdir /s /q "!SEM_EXTRACT!"
|
|
|
|
|
goto :eof
|
|
|
|
|
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM ======================================================================
|
|
|
|
|
REM Guided-install wizard (called only on interactive first runs or with
|
|
|
|
|
REM --reconfigure). Sets EXTRAS_CHOICE and INVOCABLE_CHOICE.
|
|
|
|
|
REM ======================================================================
|
|
|
|
|
:guided_wizard
|
|
|
|
|
echo.
|
|
|
|
|
echo ==========================================
|
|
|
|
|
echo PLANNOTATOR GUIDED INSTALL
|
|
|
|
|
echo ==========================================
|
|
|
|
|
echo.
|
|
|
|
|
if "!EXTRAS_PRESENT!"=="1" (
|
2026-07-10 06:50:40 -07:00
|
|
|
echo Extra skills already installed - keeping them.
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
set "EXTRAS_CHOICE=yes"
|
|
|
|
|
) else if defined EXTRAS_FLAG (
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Flag already answered this question - don't ask and then ignore.
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
set "EXTRAS_CHOICE=!EXTRAS_FLAG!"
|
|
|
|
|
) else (
|
|
|
|
|
set "DEF_EXTRAS=no"
|
|
|
|
|
if defined SAVED_EXTRAS set "DEF_EXTRAS=!SAVED_EXTRAS!"
|
|
|
|
|
set "ANSWER="
|
|
|
|
|
set /p "ANSWER=Install the extra skills (compound planning, setup-goal, visual explainer)? [y/N] "
|
|
|
|
|
set "EXTRAS_CHOICE=no"
|
|
|
|
|
if /i "!ANSWER!"=="y" set "EXTRAS_CHOICE=yes"
|
|
|
|
|
if /i "!ANSWER!"=="yes" set "EXTRAS_CHOICE=yes"
|
|
|
|
|
if "!ANSWER!"=="" set "EXTRAS_CHOICE=!DEF_EXTRAS!"
|
|
|
|
|
)
|
|
|
|
|
if defined MODEL_INVOCABLE_FLAG (
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Flag already answered this question - don't ask and then ignore.
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
set "INVOCABLE_CHOICE=!MODEL_INVOCABLE_FLAG!"
|
Plan-look chooser + 0.20.0 release dialog (with GitLab / sem / install fixes) (#879)
* feat(plan): default to the grid look + look-and-feel image chooser
- Flip gridEnabled default back to true (classic grid / floating-card look),
reverting #863's flat-by-default so existing users without an explicit
choice return to the grid view they're used to.
- Rewrite the look-and-feel announcement into a two-image chooser: Grid
(classic, now the default) vs Clean (the new flat look), each a clickable
screenshot that hover-zooms to preview — mirroring the code-review
DiffTypeSetupDialog pattern.
- Bump the announcement version (1 -> 2) so existing users are re-offered the
choice once.
- Add look-grid.png / look-flat.png preview assets (resized app screenshots).
* fix(review): restore GitLab /diffs fallback for MR review
#871's pr-gitlab refactor moved to the raw_diffs endpoint and deleted the
paginated /diffs path, hard-breaking MR review on self-hosted GitLab too old to
expose raw_diffs (opaque "Failed to fetch MR diff") and silently rendering zero
files when raw_diffs returns empty for oversized MRs.
Keep raw_diffs as the primary path (it preserves binary markers + collapsed
content), but fall back to the restored paginated /diffs + reconstructPatch when
raw_diffs fails or is empty, and throw a clear "diff is empty / too large" error
if both come back empty. Restores parsePaginatedArray / reconstructPatch and
adds tests for the fallback paths.
* fix(install): bound the optional sem sidecar download
The semantic-diff 'sem' download (#871) ran curl / Invoke-WebRequest with no
timeout. The sidecar installs after plannotator itself, so a slow or hung fetch
could wedge an otherwise-complete install. Add --connect-timeout 10
--max-time 120/60 (sh, cmd) and -TimeoutSec 120/60 (ps1) so it times out and
skips gracefully, and document the PLANNOTATOR_SKIP_SEM_INSTALL opt-out in the
installer help.
* chore(install): remove the Glimpse install option from the installers
The installers offered to `npm install -g glimpseui` (a wizard prompt +
--glimpse/--no-glimpse flags + saved pref). Drop all of it across install.sh,
install.ps1, and install.cmd: flags, usage text, the wizard question, the
glimpse_present detection, the saved-pref read/write, the persistence clauses,
and the install block. The guided wizard is now two questions (extras,
model-invocable).
Runtime Glimpse support is unchanged: the app still opens in the native window
if glimpseui is on PATH (packages/server/browser.ts), still gated by
PLANNOTATOR_GLIMPSE. Updated install.test.ts (asserts the installers are
glimpse-free) and the installation docs.
* feat(plan): 0.20.0 release announcement dialog
Turn the first-run look chooser into a two-page 0.20.0 announcement.
- Page 1: header with a "Full release notes" link, a four-up feature
grid (fresh look, semantic review, multi-repo review, leaner install),
and the grid/clean plan-look chooser.
- Page 2: "Workspaces are coming" teaser with the waitlist image + link.
- Footer actions grouped bottom-right on both pages (shimmering
"Workspaces are coming" teaser via TextShimmer + the primary action)
so focus stays in one corner across the page turn.
- Reshoot the grid/clean chooser screenshots on a clean prose plan and
add the workspaces teaser image.
* feat(plan): add full-page HTML feature card, lead with leaner install
Add a fifth what's-new card for --render-html (annotate HTML reports and
explainers rendered full-screen) and move Leaner install to the front of
the grid.
2026-06-09 09:45:20 -07:00
|
|
|
goto :eof
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
)
|
|
|
|
|
set "ANSWER="
|
|
|
|
|
set /p "ANSWER=Make any skills callable by the model (instead of user-invoked only)? [y/N] "
|
|
|
|
|
set "WANT_INVOCABLE=no"
|
|
|
|
|
if /i "!ANSWER!"=="y" set "WANT_INVOCABLE=yes"
|
|
|
|
|
if /i "!ANSWER!"=="yes" set "WANT_INVOCABLE=yes"
|
|
|
|
|
if "!WANT_INVOCABLE!"=="no" (
|
|
|
|
|
set "INVOCABLE_CHOICE=none"
|
Plan-look chooser + 0.20.0 release dialog (with GitLab / sem / install fixes) (#879)
* feat(plan): default to the grid look + look-and-feel image chooser
- Flip gridEnabled default back to true (classic grid / floating-card look),
reverting #863's flat-by-default so existing users without an explicit
choice return to the grid view they're used to.
- Rewrite the look-and-feel announcement into a two-image chooser: Grid
(classic, now the default) vs Clean (the new flat look), each a clickable
screenshot that hover-zooms to preview — mirroring the code-review
DiffTypeSetupDialog pattern.
- Bump the announcement version (1 -> 2) so existing users are re-offered the
choice once.
- Add look-grid.png / look-flat.png preview assets (resized app screenshots).
* fix(review): restore GitLab /diffs fallback for MR review
#871's pr-gitlab refactor moved to the raw_diffs endpoint and deleted the
paginated /diffs path, hard-breaking MR review on self-hosted GitLab too old to
expose raw_diffs (opaque "Failed to fetch MR diff") and silently rendering zero
files when raw_diffs returns empty for oversized MRs.
Keep raw_diffs as the primary path (it preserves binary markers + collapsed
content), but fall back to the restored paginated /diffs + reconstructPatch when
raw_diffs fails or is empty, and throw a clear "diff is empty / too large" error
if both come back empty. Restores parsePaginatedArray / reconstructPatch and
adds tests for the fallback paths.
* fix(install): bound the optional sem sidecar download
The semantic-diff 'sem' download (#871) ran curl / Invoke-WebRequest with no
timeout. The sidecar installs after plannotator itself, so a slow or hung fetch
could wedge an otherwise-complete install. Add --connect-timeout 10
--max-time 120/60 (sh, cmd) and -TimeoutSec 120/60 (ps1) so it times out and
skips gracefully, and document the PLANNOTATOR_SKIP_SEM_INSTALL opt-out in the
installer help.
* chore(install): remove the Glimpse install option from the installers
The installers offered to `npm install -g glimpseui` (a wizard prompt +
--glimpse/--no-glimpse flags + saved pref). Drop all of it across install.sh,
install.ps1, and install.cmd: flags, usage text, the wizard question, the
glimpse_present detection, the saved-pref read/write, the persistence clauses,
and the install block. The guided wizard is now two questions (extras,
model-invocable).
Runtime Glimpse support is unchanged: the app still opens in the native window
if glimpseui is on PATH (packages/server/browser.ts), still gated by
PLANNOTATOR_GLIMPSE. Updated install.test.ts (asserts the installers are
glimpse-free) and the installation docs.
* feat(plan): 0.20.0 release announcement dialog
Turn the first-run look chooser into a two-page 0.20.0 announcement.
- Page 1: header with a "Full release notes" link, a four-up feature
grid (fresh look, semantic review, multi-repo review, leaner install),
and the grid/clean plan-look chooser.
- Page 2: "Workspaces are coming" teaser with the waitlist image + link.
- Footer actions grouped bottom-right on both pages (shimmering
"Workspaces are coming" teaser via TextShimmer + the primary action)
so focus stays in one corner across the page turn.
- Reshoot the grid/clean chooser screenshots on a clean prose plan and
add the workspaces teaser image.
* feat(plan): add full-page HTML feature card, lead with leaner install
Add a fifth what's-new card for --render-html (annotate HTML reports and
explainers rendered full-screen) and move Leaner install to the front of
the grid.
2026-06-09 09:45:20 -07:00
|
|
|
goto :eof
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
)
|
chore: remove the redundant /plannotator-status and /plannotator-archive commands (#873)
Two agent command-surface cleanups. Both remove only the command entry points; all underlying infrastructure stays.
1. /plannotator-status (Pi): removed — it echoed phase/plan-file/progress on
demand, but that state is already shown ambiently (status bar + live
checklist widget). The phase/checklist state machine is untouched.
2. /plannotator-archive (all agents): removed the command/skill entry points
across every surface — Claude/Codex/Kiro skills, Pi, OpenCode (handler +
dispatch + cli-bridge + embedded + stub), Droid, the Kiro agent prompt, all
three installers, docs, marketing, and the CI deprecated-command guard. The
installers also gained a stale-skill cleanup so upgraders drop a previously
installed plannotator-archive skill.
Kept (infrastructure) — archive browsing stays available in-review via the
sidebar: the `plannotator archive` CLI subcommand (apps/hook/server), the
mode:"archive" server path + /api/archive endpoints, ArchiveBrowser/useArchive,
the sidebar Archive tab, sessions.ts "archive" mode, and ~/.plannotator/plans
storage.
Verified: bun test scripts/install.test.ts → 72 pass; pi-extension typecheck +
build:opencode pass; repo-wide residual scan clean; KEEP-set integrity
confirmed; one orphaned import (opencode commands.ts) caught in self-review and
removed.
2026-06-08 11:08:11 -07:00
|
|
|
set "SKILL_COUNT=3"
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
set "SKILL_1=plannotator-review"
|
|
|
|
|
set "SKILL_2=plannotator-annotate"
|
|
|
|
|
set "SKILL_3=plannotator-last"
|
|
|
|
|
if "!EXTRAS_CHOICE!"=="yes" (
|
chore: remove the redundant /plannotator-status and /plannotator-archive commands (#873)
Two agent command-surface cleanups. Both remove only the command entry points; all underlying infrastructure stays.
1. /plannotator-status (Pi): removed — it echoed phase/plan-file/progress on
demand, but that state is already shown ambiently (status bar + live
checklist widget). The phase/checklist state machine is untouched.
2. /plannotator-archive (all agents): removed the command/skill entry points
across every surface — Claude/Codex/Kiro skills, Pi, OpenCode (handler +
dispatch + cli-bridge + embedded + stub), Droid, the Kiro agent prompt, all
three installers, docs, marketing, and the CI deprecated-command guard. The
installers also gained a stale-skill cleanup so upgraders drop a previously
installed plannotator-archive skill.
Kept (infrastructure) — archive browsing stays available in-review via the
sidebar: the `plannotator archive` CLI subcommand (apps/hook/server), the
mode:"archive" server path + /api/archive endpoints, ArchiveBrowser/useArchive,
the sidebar Archive tab, sessions.ts "archive" mode, and ~/.plannotator/plans
storage.
Verified: bun test scripts/install.test.ts → 72 pass; pi-extension typecheck +
build:opencode pass; repo-wide residual scan clean; KEEP-set integrity
confirmed; one orphaned import (opencode commands.ts) caught in self-review and
removed.
2026-06-08 11:08:11 -07:00
|
|
|
set "SKILL_COUNT=6"
|
|
|
|
|
set "SKILL_4=plannotator-compound"
|
|
|
|
|
set "SKILL_5=plannotator-setup-goal"
|
|
|
|
|
set "SKILL_6=plannotator-visual-explainer"
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
)
|
2026-07-10 06:50:40 -07:00
|
|
|
REM Preselect previously chosen skills. NOTE: no pipes here - each side of a
|
Single-source skills (core/extra), replace Claude Code commands with skills, de-hardcode installers (#850)
* feat: single-source skills into core/extra, replace Claude commands with skills, de-hardcode installers
- apps/skills/core/{review,annotate,last,archive}: single authoritative
source for the always-installed skills (archive is new); all carry
disable-model-invocation + agents/openai.yaml sidecars
- apps/skills/extra/{compound,setup-goal,visual-explainer}: no longer
default-installed (except Kiro); installers print an
`npx skills add backnotprop/plannotator/apps/skills/extra` suggestion
- Claude Code: apps/hook/commands/ deleted, command heredocs removed;
core skills in ~/.claude/skills are the slash commands now
- Installers: OpenCode/Gemini command files copied from an extended
sparse checkout instead of heredocs; install.cmd gains the previously
missing OpenCode command install; aggressive cleanup of legacy
~/.claude/commands and ~/.codex/skills artifacts
- Codex: core skills install to ~/.agents/skills (official path);
~/.codex/skills install removed
- Pi: extension no longer bundles skills; #670 settings filter removed
* fix: review findings — old-tag soft guards, cmd replace-not-merge, plugin-update hint, frontmatter test
- install.sh: a --version tag predating apps/skills/core no longer aborts
the whole copy subshell (which also skipped OpenCode/Gemini commands);
core skills now soft-skip with an accurate message, matching ps1/cmd
- install.sh: subshell failure message no longer claims "git required"
when git was present (clone/network errors get their own wording)
- install.cmd: pre-remove skill dirs before xcopy so upgrades replace
rather than merge (stale files from renamed/deleted skill files no
longer linger; parity with sh/ps1)
- all installers + docs: tell upgraders to run /plugin marketplace update
so the plugin's old namespaced plannotator:* commands disappear (#817)
- install.test.ts: assert every core SKILL.md sets
disable-model-invocation: true — the load-bearing line that keeps core
skills out of Pi's system prompt (#842 regression guard)
* test: pin old-tag soft-guard behavior, dedupe core-skill list in tests
* fix: interrogation review findings — cross-installer diagnostic parity
- install.ps1/install.cmd: emit the "predates the core/extra skill
layout" diagnostic on old pinned tags instead of silently skipping
core skills (parity with install.sh)
- install.ps1: clone/network failure no longer claims "git required"
(git was already verified present); the outer catch now reports the
actual exception
- install.sh: "Installed OpenCode/Gemini commands" echoes are guarded
on the copy actually having a source, so old pinned tags don't print
false success (ps1/cmd already gated this way)
- AGENTS.md: opencode-plugin commands/ comment now reflects all four
command stubs
- install.test.ts: shared test asserts the soft-skip diagnostic exists
in all three installers and pins ps1's honest failure wording
* fix: respect CODEX_HOME for Codex home directory (#852)
Codex stores config and state under $CODEX_HOME when set, falling back
to ~/.codex (developers.openai.com/codex/config-advanced). Plannotator
hardcoded ~/.codex in two places:
- runtime: codex-session.ts scanned ~/.codex/sessions for rollout
files, so `plannotator last` failed with "No rendered assistant
message found" when CODEX_HOME pointed elsewhere. Now resolved the
same way copilot-session.ts handles COPILOT_HOME and session-log.ts
handles CLAUDE_CONFIG_DIR.
- installers: detection, config.toml/hooks.json paths, manual-setup
instructions, and the stale-skills cleanup now derive from
CODEX_HOME in all three scripts.
Tests: codex-session.test.ts covers rollout discovery under a
CODEX_HOME temp dir; install.test.ts asserts all three installers
respect the variable and that the fallback is the only hardcoded
~/.codex path left in install.sh.
* fix: hard-fail skill install, guard command cleanup, one-time extras migration
External review triage on PR #850 surfaced two real installer issues:
P1 — commands deleted before replacement: the Claude command cleanup
ran before the git-gated skill install, so a missing git, a failed
clone, or an old pinned tag deleted the user's slash commands and
installed nothing (a regression — the old installer needed no git).
Now:
- missing git is a hard failure before anything is touched ("install
git, then run this installer again")
- a failed fetch is a hard failure ("something went wrong — run the
installer again") instead of a silent skip
- the legacy command cleanup runs AFTER the install and only removes a
command file when its same-name replacement skill exists on disk
- old pinned tags keep the soft-skip (no deletion happens, commands
survive, CI e2e against old tags stays green)
P2 — recurring extras deletion: the extras cleanup ran on every
invocation, deleting copies users reinstalled via the suggested
`npx skills add` (the copies are byte-identical, so only provenance
can tell them apart). The cleanup is now a one-time migration recorded
in a migrations ledger under the Plannotator data dir
(<PLANNOTATOR_DATA_DIR|~/.plannotator>/migrations/), the same
record-what-you-did pattern package managers use.
All three installers (sh/ps1/cmd) updated in parity; tests pin the
guard condition, the ledger gating, and the hard-fail messages.
* test: tripwire — install.cmd must never contain /dev/null redirects
* fix: every skill sets disable-model-invocation — no exceptions
Maintainer rule: all Plannotator skills are user-invoked, never
model-auto-invoked. setup-goal (missing since #665) and the three Kiro
skills now carry the flag. The frontmatter test scans every SKILL.md in
apps/skills/core, apps/skills/extra, and apps/kiro-cli/skills
dynamically — with a floor of 10 — so a future skill cannot ship
without it.
* docs: git is a hard installer requirement; clarify post-gate sections complete on re-run
* docs: align ps1/cmd comments with hard-fail semantics
* feat: guided install — extras opt-in via skills CLI, model-invocation picker
Interactive terminals get a two-question wizard on first run:
1. Install the extra skills? Yes delegates to `npx skills add
backnotprop/plannotator/apps/skills/extra` (its UI picks the agents),
wired to /dev/tty so piped curl|bash installs still work. Skipped
when extras already exist on disk.
2. Make any skills callable by the model? Yes opens a space-toggle
checkbox (sh/ps1) or numbered toggles (cmd), listing all skills if
extras were chosen, core-only otherwise. Chosen skills get
disable-model-invocation stripped from their INSTALLED copies and the
Codex sidecar's allow_implicit_invocation flipped — re-applied every
run since installs replace skill folders. Repo sources stay locked.
Answers persist to <data dir>/install-prefs (shared format across all
three installers) and re-runs reuse them silently; --reconfigure
re-opens the wizard. Automation is untouched: no terminal means no
prompts and today's defaults; --extras/--no-extras/--model-invocable/
--non-interactive give scripts explicit control.
* fix: self-review of guided install — cmd pipe expansion bug, flag/wizard interplay
- install.cmd: the checkbox preselection used `echo !var! | findstr` —
each side of a cmd pipe runs in a child WITHOUT delayed expansion, so
the saved choices passed through as literal !var! text and
preselection never matched. Replaced with a substring-replace
containment test (no pipe).
- all three: a wizard question whose answer was already provided by a
CLI flag (--extras/--no-extras/--model-invocable) is no longer asked
and then silently overridden — the flag pre-answers it.
- install.cmd: unknown-option usage line now lists the wizard flags.
* feat: guided install question 3 — install Glimpse (native window)
glimpseui (third-party npm package, PR #840) gives Plannotator a native
WebView window instead of a browser tab; the runtime already
auto-detects it on PATH, so a global install is all that's needed.
- Wizard asks "Install Glimpse?" (default yes) after the skills
questions; skipped when glimpseui is already on PATH
- Yes runs `npm install -g glimpseui` (bun fallback on sh/ps1; printed
instruction when neither exists) — wizard or explicit flag only,
silent re-runs never install software
- --glimpse / --no-glimpse flags for automation; choice persisted to
install-prefs like the others
- docs + tests updated (glimpse detection, install command, flags, and
persist-condition assertions across all three installers)
* fix: self-review of Glimpse question — cmd bun fallback, stale usage text
* fix: merge-window hardening — guard Codex cleanup, remove old-installer junk dirs
plannotator.ai serves install.sh live from main (public/ symlink,
deployed on push), while the script fetches repo files at the LATEST
RELEASE TAG. Between merging the core/extra restructure and cutting the
release that ships it, the live script runs against the old-layout tag.
Two hazards in that window:
1. The Codex stale-skill cleanup removed working ~/.codex/skills with
no successor installed (core skills soft-skip on old tags). Now the
cleanup runs AFTER the install and removes a core skill only once
its replacement exists in ~/.agents/skills — same guard the Claude
command cleanup uses. The compound/setup-goal stale copies stay
unconditional (never Codex's to begin with).
2. The reverse combo (cached OLD script + NEW release tag) wholesale-
copies apps/skills/* and leaves junk core/ and extra/ directory
copies in ~/.claude/skills. Never valid skill names — all three
installers now remove them on every run.
* fix: glimpseui is a devDependency — consumers never use it from node_modules
PR #840 added glimpseui to dependencies in @plannotator/server and
@plannotator/pi-extension, but nothing imports it: both runtimes detect
the CLI on PATH (Bun.which / a manual PATH walk) and spawn it. The dep
only ever mattered in repo development, where `bun run` prepends
node_modules/.bin to PATH. For consumers it was inert download weight —
OpenCode plugin installs and `pi install` pulled a third-party package
that could never be detected (Pi's loader does not expose
node_modules/.bin; verified). Moved to devDependencies in both: dev
flows keep working, published packages stop shipping it. The sanctioned
end-user path is the guided installer's global `npm install -g
glimpseui`.
* fix: clean stale plugin command files from the installed plugin checkout (#817)
The installer already manages hooks.json inside
~/.claude/plugins/marketplaces/plannotator/apps/hook/, so the earlier
"don't reach into plugin storage" rationale for leaving the old
namespaced plannotator:* command files there was inconsistent. All
three installers now remove them — same replacement-skill guard as the
bare ~/.claude/commands cleanup — making the #817 duplicate menu
entries die on a single installer run + restart instead of waiting for
/plugin marketplace update. Hints/docs reworded accordingly.
* Revert "fix: clean stale plugin command files from the installed plugin checkout (#817)"
This reverts commit 3df37da92cdf26b1673b0ab1a5930fdcef8fc202.
* fix: Windows CI — assert the new no-commands contract; gate cmd wizard on a real console
The cmd e2e CI step still asserted the OLD contract (installer writes
~/.claude/commands/plannotator-*.md with the ! prefix). Commands are
dead; the step now guards the NEW contract: a fresh install must write
NO plannotator command files. The Gemini TOML assertions stay — they
now verify the verbatim checkout copy delivers intact files (the tag
the e2e pins, v0.17.1, contains apps/gemini/commands).
The failure also exposed that install.cmd ran the wizard on redirected
stdin (set /p falls through to defaults at EOF) — and Q3's default
being yes meant CI silently ran `npm install -g glimpseui`. cmd now
probes for a real console via `timeout /t 0` (errors when stdin is
redirected), matching sh's /dev/tty and ps1's IsInputRedirected gates:
no console, no wizard, no wizard-only installs.
2026-06-05 09:23:45 -07:00
|
|
|
REM cmd pipe runs in a child without delayed expansion, so !vars! would pass
|
|
|
|
|
REM through literally. A substring-replace containment test avoids that trap.
|
|
|
|
|
set "PRESEL=,!SAVED_INVOCABLE!,"
|
|
|
|
|
for /l %%I in (1,1,!SKILL_COUNT!) do (
|
|
|
|
|
set "SEL_%%I=0"
|
|
|
|
|
if defined SAVED_INVOCABLE (
|
|
|
|
|
for %%K in ("!SKILL_%%I!") do if not "!PRESEL:,%%~K,=!"=="!PRESEL!" set "SEL_%%I=1"
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
:toggle_loop
|
|
|
|
|
echo.
|
|
|
|
|
for /l %%I in (1,1,!SKILL_COUNT!) do (
|
|
|
|
|
set "MARK= "
|
|
|
|
|
if "!SEL_%%I!"=="1" set "MARK=x"
|
|
|
|
|
echo %%I^) [!MARK!] !SKILL_%%I!
|
|
|
|
|
)
|
|
|
|
|
set "PICK="
|
|
|
|
|
set /p "PICK=Toggle a number (press enter on empty input to confirm): "
|
|
|
|
|
if "!PICK!"=="" goto :collect_invocable
|
|
|
|
|
set "VALID=0"
|
|
|
|
|
for /l %%I in (1,1,!SKILL_COUNT!) do if "!PICK!"=="%%I" set "VALID=1"
|
|
|
|
|
if "!VALID!"=="0" (
|
|
|
|
|
echo Invalid choice: !PICK!
|
|
|
|
|
goto :toggle_loop
|
|
|
|
|
)
|
|
|
|
|
for %%I in (!PICK!) do (
|
|
|
|
|
if "!SEL_%%I!"=="1" (set "SEL_%%I=0") else (set "SEL_%%I=1")
|
|
|
|
|
)
|
|
|
|
|
goto :toggle_loop
|
|
|
|
|
:collect_invocable
|
|
|
|
|
set "INVOCABLE_CHOICE="
|
|
|
|
|
for /l %%I in (1,1,!SKILL_COUNT!) do (
|
|
|
|
|
if "!SEL_%%I!"=="1" (
|
|
|
|
|
if defined INVOCABLE_CHOICE (set "INVOCABLE_CHOICE=!INVOCABLE_CHOICE!,!SKILL_%%I!") else (set "INVOCABLE_CHOICE=!SKILL_%%I!")
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
if not defined INVOCABLE_CHOICE set "INVOCABLE_CHOICE=none"
|
|
|
|
|
goto :eof
|