mirror of
https://github.com/backnotprop/plannotator.git
synced 2026-09-14 14:17:26 +08:00
main
82 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Michael Ramos
|
d749c55c02 |
chore: scrub personal paths and untrack local-only artifacts
- Anonymize the real project paths and ticket prefix in session-log test fixtures (slug expectations updated to match). - Untrack scripts/convert-themes.ts: a one-shot migration script hardcoding a path into an unrelated private project; its output in packages/ui/themes/ is already committed. - Delete the three unreferenced sprite_package_*/index.html preview pages, which also shipped in the @plannotator/ui npm tarball via the wholesale directory entries in files. |
||
|
Michael Ramos
|
7ee366d8a1 |
fix(opencode): show the session URL on OpenCode 2's native command path (#1435)
* fix(opencode): show the session URL on OpenCode 2's native command path
On OpenCode 2 a remote session's URL was invisible. runNativeCommand builds
its bridge client with createV2BridgeClient, which deliberately has no tui
domain, so toastPlannotatorUrl optional-chained to a no-op; both URL delivery
paths (the CLI stderr forwarder and the ready-file poller) route through it.
The V2 client's app.log is console.error, and OpenCode discards a server
plugin's stderr under both default launch modes (packages/cli/src/services/
standalone.ts uses stderr: "ignore" unless OPENCODE_PRINT_LOGS=1). Remote mode
also suppresses the browser, so /plannotator-review showed the user nothing at
all and presented as a hang.
Deliver the URL as a visible transcript notice instead. createSessionUrlNotifier
duck-types ctx.session.synthetic and exposes it to cli-bridge as notifyUrl, a
seam toastPlannotatorUrl prefers over the toast when present; OpenCode 1 clients
carry no notifyUrl and keep their real toast unchanged. The notice is posted
with resume: false, which upstream skips the wake for, so nothing starts a model
turn, and it carries the URL in both text and description because the TUI drops
a synthetic row whose description is empty and renders the description rather
than the text. Everything is guarded: a host without session.synthetic, or a
call with no session, gets no notifier and falls back to today's log-only
behavior, and a rejecting synthetic is caught and leaves the URL retryable by
the other delivery path.
The README's remedy line claimed remote sessions should read the URL from the
OpenCode log, which was never true; it now describes the transcript notice and
names OPENCODE_PRINT_LOGS=1 for older hosts.
Also fixes two bugs in the OpenCode 2 native-command smoke:
- scripts/opencode2-native-commands-smoke.sh looked for a node_modules/.bin/
opencode binary. @opencode-ai/cli publishes opencode2 on every dist-tag, so
the script failed before it started a server. It now tries both names and
reports which it looked for.
- The command-ownership check read /api/command once, immediately after
activation, racing the reclaim schedule whose last tick lands about 15.5s
later. Under PLANNOTATOR_SMOKE_EXPECT_NATIVE=1 that reported a shadowing bug
the reclaim had simply not reached yet. It now polls to a 30s deadline
(PLANNOTATOR_SMOKE_COMMAND_TIMEOUT_MS), still only after /api/plugin reports
the plugin loaded.
AI-assisted (Claude) under maintainer direction.
* fix(opencode): deliver the session URL on OpenCode 2's plan review path too
The first commit fixed only the native command path. The plan path builds its
own client (createV2Client, typed as { app: { agents, log } } with no notifier),
so a remote OpenCode 2 user who reached a review through submit_plan still never
saw the URL: no browser is opened for them and the plugin's console output is
discarded by the host.
The plan path now builds the same bridge client the command path uses, with
toolContext.sessionID, so it carries notifyUrl whenever the host exposes
session.synthetic. That covers both runtimes: the CLI runtime already prefers
notifyUrl inside toastPlannotatorUrl, and the embedded runtime's previously
empty logReady hook is now createPlanReadyNotifier.
That hook still does not log. app.log is console.error, the same stderr
handleServerReady already printed the URL to, so logging there would duplicate
the line in remote mode and add a stray one locally, which is why the hook was
empty. The transcript notice is a different surface, and it is the only one a
remote reviewer can see. Without session.synthetic the hook stays silent exactly
as before.
createV2Client is gone: it duplicated the bridge client's URL-deduped app.log
verbatim, and nothing else used it.
Three tests on the plan path (delivers the notice; stays silent and does not
re-log without synthetic; catches a rejecting notice) plus one that pins the two
wiring seams at source level, since the notifier tests all pass while the plan
path is wired to nothing, which is the shape the bug had.
Also from review: console.error is stubbed across the V2 URL delivery block, so
those tests no longer print URL lines into the suite output. The README bullet
now says the notice covers every way a session opens rather than slash commands
alone.
AI-assisted (Claude) under maintainer direction.
|
||
|
Michael Ramos
|
82a8f236ec |
feat(opencode): restore the slash commands on OpenCode 2 (#1434)
* feat(opencode): restore the slash commands on OpenCode 2 OpenCode's V2 plugin API gained native command execution upstream (anomalyco/opencode issue #2185, PR #44765): ctx.command.transform lets a plugin add a command whose execute callback fully owns the invocation. That shape currently ships on the beta and dev dist-tags of @opencode-ai/plugin while next and latest still carry the older context, so the capability is duck-typed at runtime and never imported. On a host that exposes it the V2 adapter registers /plannotator-review, /plannotator-annotate and /plannotator-last and runs the same handleCliCommand machinery OpenCode 1 uses, passing the raw argument tail straight through to the CLI. On a host without it nothing new is registered and behavior is byte-identical to before. Also wires ctx.session.switchAgent (same API generation, same probe) so an agent switch chosen in the review UI is applied instead of only warned about, and accepts both agent.list() response shapes: the HTTP client types it as a { location, data } envelope while the in-process plugin domain answers with a bare array, where reading .data threw and silently emptied the agent list. The shared command stubs get model-mediated fallback bodies for OpenCode 2 hosts on the stale channels. They carry no shell interpolation on purpose: OpenCode 1 evaluates a template's !`...` before the V1 plugin's command.execute.before hook can clear the parts, so a bang template there would launch a second Plannotator session on every OC1 invocation. A source level test pins that. AI-assisted (Claude) under maintainer direction. * fix(opencode): probe the command draft and reclaim the names from the stubs Review found the capability probe was wrong in the direction that matters. ctx.command.transform exists on pre-#44765 hosts too: our own pinned @opencode-ai/plugin@0.0.0-next-16775 declares CommandDraft as { list, get, update, remove } with no add. The probe therefore returned true on next and latest, draft.add was undefined, and because transforms are stored and replayed the TypeError landed in the batched reload flush and aborted it before commit, plausibly taking every command registration on the host down with it. Capability is now read from the draft handed to the callback, which is the only witness, and the registration call is wrapped so no transform rejection can fail plugin setup. The stubs also shadowed the native definitions on new hosts. Command definitions land in a name-keyed map where add is Map.set, transforms replay in registration order, and OpenCode's own ConfigCommandPlugin activates in the post group after package plugins while scanning the exact directory the installer writes the three stubs to. A setup-time registration is therefore always overwritten on a normal install. The plugin now re-registers the same transform once activation settles, so its definitions are last in the replay order, and calls ctx.command.reload() explicitly because a late registration only adds its reload to the already-flushed boot batch. Ownership is read back from ctx.command.list() by description, which is why the native descriptions and the stub frontmatter are deliberately distinct. If the reclaim cannot run the stubs keep the names and the commands still work through their fallback bodies. Also: a failing switchAgent no longer costs the reviewer their feedback on the command path, feedback is delivered as "queue" rather than replaying the invocation's admission mode minutes later when a steer would land mid-turn, and the agent-list comment no longer asserts a bare-array response that could not be reproduced upstream (accepting both shapes is still right, since reading .data blindly throws into a catch that degrades silently). Tests: the real old-host draft shape registers nothing and throws nothing, the shadowing contest is modelled against upstream's replay semantics, the OpenCode 1 parts-clearing invariant is pinned for all three commands in both plan-agent and manual mode now that the stubs carry real instructions, and the V2 smoke asserts the plugin did not activate as failed and that all three commands resolve. The smoke now also installs the stubs into its sandbox config dir so the contest actually happens there. scripts/opencode2-native-commands-smoke.sh runs the same smoke against a dev-channel build with native commands required; CI cannot, because it pins a next build. AI-assisted (Claude) under maintainer direction. * fix(opencode): keep the reclaim ticking and stop an unbuilt checkout failing setup The reclaim ended the loop when the draft-probe flag read false, but that flag only flips when the transform replays, which under boot batching is the flush after every plugin has loaded. Plannotator loads before the post-group config plugins, so the first tick legitimately reads false and the loop exited for good: the reclaim was inert in exactly the shape production has. The tick is skipped now instead, with a test that flips the flag between ticks. The V1 entry called resolveBundledHtmlPath synchronously during plugin construction, outside the .catch that was there to absorb a missing asset, so an unbuilt checkout threw out of construction before any code path that needs the HTML. The Test workflow runs bun test with no build step, so the new OpenCode 1 interception tests failed there. Both preloads are guarded; the lazy getters still raise a clear error if something actually needs the file. The smoke's failed-plugin guard read entry.state.status, but Plugin.Info carries status and error at the top level, so a failed activation slipped through. Reads the top level first and keeps the nested one as a fallback. Comment corrections: State.batch clears its active flag before flushing, so a late transform registration materializes on its own; the explicit reload() is redundant-but-defensive rather than required. The reclaim schedule is a list of deltas the loop awaits in turn, so the ticks land near 0.3s, 1.5s, 5.5s and 15.5s, not at the raw numbers. AI-assisted (Claude) under maintainer direction. |
||
|
Michael Ramos
|
db86d38ca4 |
feat(skills): top-level plannotator knowledge skill, per-host install, and plannotator.ai/llms.txt (#1377)
* feat(skills): add the plannotator knowledge-layer skill with a CLI freshness guard A new model-invocable core skill (apps/skills/core/plannotator) that teaches an agent the whole CLI surface: decision guide, per-command reference with flags and exit codes, env vars, the external-annotations API, and a do-not list. The existing plannotator-* core skills stay lightweight action stubs. A freshness test (apps/hook/server/plannotator-skill-reference.test.ts) parses the skill's documented subcommands and flags and diffs them against cli.ts usage text plus the CLI arg-parsing sources, in both directions, so the reference cannot drift from the real CLI without failing the suite. Installers copy the single-sourced core body into ~/.claude/skills and ~/.agents/skills on all three platforms; uninstall removes it from both scopes. The skill ships model-invocable as a documented exception to the locked-by-default rule, asserted both ways in install.test.ts. * feat(marketing): serve the plannotator knowledge skill as /llms.txt Single-sourced at build time from apps/skills/core/plannotator/SKILL.md per the llmstxt.org spec (H1, blockquote, detail sections, Docs link list), so the CLI freshness guard transitively keeps llms.txt current. * fix(skills): reach every install path with the plannotator knowledge skill The knowledge skill reached Claude Code and ~/.agents but was missing from three install paths. Six fixes from the install-reach review of #1377. Kiro: the installer's Kiro leg copied only the two action skills, so Kiro users got launchers and no CLI reference. One copy line per installer, and "plannotator" joins uninstall.ts's KIRO_SKILLS. OpenCode npm: @plannotator/opencode's postinstall copied only commands/*.md. The package now ships the skill (copied at build time like the HTML assets, gitignored so the shipped copy cannot drift) and postinstall places it under ${XDG_CONFIG_HOME:-$HOME/.config}/opencode/skills/plannotator/, which is a path OpenCode really scans ({skill,skills}/**/SKILL.md under xdgConfig/ opencode). Uninstall sweeps it, skills only, so a user's own opencode/commands/plannotator.md stays out of scope. Pi npm: vendor.sh copies the skill to apps/pi-extension/skills/plannotator/ and package.json declares it under pi.skills, which Pi resolves relative to the package root. Neither vendored copy carries the // @generated header the .ts files use: a SKILL.md must open with its frontmatter on line 1. llms.txt: the endpoint resolved the skill through process.cwd(), which breaks under any invocation but --cwd apps/marketing. new URL(import.meta.url) does not fix it either, because Vite rewrites import.meta.url to the emitted SSR chunk's location. Inlined with Vite's ?raw, resolved by the bundler relative to the source file. Also drops the summary paragraph the required blockquote already carries; SKILL.md itself is unchanged. Uninstall: KNOWLEDGE_SKILLS is a separate list from CORE_SKILLS precisely so the bare name "plannotator" cannot leak into LEGACY_COMMAND_NAMES or STALE_CODEX_SKILLS and delete a user's own files. Nothing tested that; now a test proves the five installed scopes are removed and commands/plannotator.md (Claude and OpenCode) plus ~/.codex/skills/plannotator survive. Also cleanupStaleSkillLayout now knows KNOWLEDGE_SKILLS. Origins: oh-my-pi (#1373) was missing from SKILL.md's PLANNOTATOR_ORIGIN row. The guard now imports AGENT_CONFIG and asserts the row names every key and invents none, and its header comment is narrowed to what it actually proves: bidirectional for subcommands and origins, one-directional for flags. AI-assisted (Claude) under maintainer direction. |
||
|
Michael Ramos
|
2ca55c8332 |
feat(annotate): live local app annotation through a loopback reverse proxy (#1352)
* feat(bridge): additive live-mode gate + LIVE_BRIDGE_BOOTSTRAP Adds the config-gated live branch to BRIDGE_SCRIPT: frame gate, pinned parent origin, token-stamped postToParent, origin+token checks on both inbound handlers, pinpoint-only clamp, vim and resize off, pageUrl on ready, and coalesced page-change reporting for SPA history navigation. With no config present (srcdoc) every branch is inert and behavior is unchanged; the existing html-viewer suites pass unmodified as the regression proof. LIVE_BRIDGE_BOOTSTRAP installs the annotation CSS from the JSON config prelude before the IIFE runs. New package export exposes the string constants without the React barrel. * feat(ui): live-session parent side for proxied app annotation useHtmlAnnotation gains a live option (origin + token validated before parseBridgeMessage; token + concrete targetOrigin on every outbound post) and a validated page-change message with onPageChange. HtmlViewer gains src/liveSession/currentPageUrl/onPageChange: src-mode iframe with no sandbox and no srcdoc, ready pageUrl handling, per-page restore filtering with explicit clear-marks + re-sync on navigation, and one postToBridge choke point for its direct posts. Annotation.pageUrl is additive; exportAnnotations groups by page (with global numbering kept) only when a pageUrl is present, byte-identical otherwise. AnnotationPanel shows the page label; AnnotationToolstrip can hide the input switch. The editor app wires mode annotate-app: full-viewport live surface, forced pinpoint, vim off, diff/share hidden, pageUrl stamping. * feat(server): loopback reverse proxy for live app annotation Whole-origin mirror of a local dev server on a dedicated 127.0.0.1 port: streaming bridge injection (after the head open tag, before a bare </head>, or appended; exactly one per document; 8-byte holdback plus a state machine for tags split across chunks), header hygiene (upstream Host rewrite, X-Forwarded-*, identity Accept-Encoding on document intent only, hop-by-hop strip), CSP drop-and-replace with frame-ancestors listing the editor origins, X-Frame-Options removal, target-origin Location rewrite, byte-identical passthrough for assets and encoded HTML (no injection, once-per-session diagnostic), SSE streaming, and WebSocket passthrough with a bounded pending queue for HMR. Host header validation runs before any upstream contact; the bind is the literal loopback constant and the advertised-URL override is never applied. Tests boot a fake dev server and cover injection, hygiene, fidelity, WS echo, and the security posture. * feat(annotate): annotate-app server mode + CLI live probe with remote hard-off startAnnotateServer gains mode annotate-app and a liveApp option: it throws under PLANNOTATOR_REMOTE, generates the per-session token, composes the proxy-served bridge body (JSON config prelude with both editor origin forms, localhost first, plus bootstrap and bridge supplied by the caller so packages/server never imports @plannotator/ui), starts the loopback proxy after the annotate port is known, serves the live /api/plan payload (no rawHtml, no version fields, sharing off), and stops the proxy with the server. Version history and durable submission records stay excluded via the explicit mode gate. The CLI resolution probes loopback http URLs (3s, accept text/html) and defaults them to live mode when the probe returns HTML; --static forces conversion, --app forces live and fails loudly on non-loopback, https, unreachable, or non-HTML targets; both flags are mutually exclusive transport-shape flags never echoed in the tolerant handoff. A live resolution under PLANNOTATOR_REMOTE is a startup failure suggesting --static. OpenCode and Pi parsers are untouched this phase. * test(live-annotate): protocol, server, and probe suites + smoke script + docs htmlLiveProtocol.test.tsx covers the parent trust boundary (origin and token rejection before parseBridgeMessage, token + targetOrigin on every outbound post, validated page-change and ready pageUrl, per-page restore filtering with full-list numbering) and the bridge live gate, executed as the composed config + bootstrap + bridge body inside a dedicated harness iframe so the srcdoc suites keep running the same script uncontaminated in this process. annotate.test.ts gains annotate-app cases (live payload shape, composed bridge served by the proxy, no-history version endpoints, proxy stopped with the server, remote rejection); annotate-live-resolution.test.ts covers the probe matrix. The two post helpers now drop unmatched-targetOrigin posts silently, matching browser semantics where some DOM environments throw. Adds the manual Vite/Next smoke script and the AGENTS.md live app annotation section (phase gate, security posture, limitations). * test(annotate-cli): cover the CLI layer of the live app remote hard-off Spawns the real CLI entry (async, so the in-process fake app can answer the live probe) with PLANNOTATOR_REMOTE=1 against a loopback HTML server and asserts the startup-failure exit with the --static hint. Completes per-layer coverage of the three-layer hard-off (CLI exit, server throw, unconditional loopback proxy bind). * fix(live-annotate): harden the loopback trust boundary end to end - isLoopbackHostname (now canonical in live-proxy.ts, re-exported by the CLI resolution) requires localhost, ::1, or a LITERAL 127/8 IPv4 address: DNS names like 127.0.0.1.evil.example no longer classify as loopback, so neither the default probe nor --app can start a live proxy against an off-box origin. - The live-eligibility probe judges the FINAL response URL: a target that redirects off its loopback origin falls back to the static pipeline (or fails loudly under --app) instead of opening a live session whose iframe immediately leaves the proxy. - WS upgrades with a browser Origin not naming the proxy itself are refused, so a hostile page's cross-site connect is never laundered into the origin-less shape dev servers trust as a non-browser client (Vite CVE-2025-24010 class). - /__plannotator__/bridge.js refuses cross-site/same-site Sec-Fetch-Site fetches: the per-session token is no longer readable via an off-origin script include on modern browsers. - X-Frame-Options is stripped only on HTML responses (where frame-ancestors replaces it); non-HTML responses keep the app's own framing protection. - Redirect Locations are re-anchored by loopback-host + port equivalence instead of a string prefix: alternate loopback spellings are now caught and lookalike ports (5173 vs 51730) pass through untouched. - --app on a non-URL target fails loudly instead of being silently swallowed. * fix(live-annotate): session correctness for SPA restores, origins, and pathful targets - A live find-and-mark that resolves nothing keeps its record, seeded with unresolved placeholder targets from the durable anchor/text params, so the mutation-driven reconcile re-acquires the pin once a lazy route or data-dependent tree renders (SPA navigation no longer permanently drops pins). Srcdoc restores keep the fail-closed drop. - The bridge posts every outbound message once per listed editor origin; the browser delivers only the one matching the parent document, so an editor opened at 127.0.0.1 instead of localhost no longer silently loses ready and every subsequent message. - The advertised appUrl is the proxy under its localhost spelling with the target URL's own path and query: the framed app stays same-site with the editor, shares the dev app's host-only localhost cookies and storage, and a pathful target opens its page instead of the app root. The proxy still binds the 127.0.0.1 literal. * ci(live-annotate): run the live protocol DOM suite; document the hardened posture htmlLiveProtocol.test.tsx is DOM-gated and was absent from the workflow's DOM_TESTS file list, so none of its trust-boundary assertions ran in CI. Add it, and update the live-app section of the project docs: literal-loopback gate, probe redirect rule, WS Origin check, bridge.js delivery gate, localhost appUrl advertisement, live restore resilience, and the remote-mode behavior change (loopback URL annotate under PLANNOTATOR_REMOTE now exits asking for --static instead of silently converting). * fix(live-annotate): absorb the v0.27 mainline into the live session surface Post-rebase seam work after replaying the branch onto main (v0.27.4 era): - Route the bridge's unanchored-transparency report through postToParent so live sessions deliver it token-stamped to the listed editor origins; the raw '*' post main introduced for srcdoc would be dropped by the live parent's message authentication exactly where restores fail most. New live-harness test pins the contract. - Extend the live remote hard-off to --tailscale sessions (flag postdates the branch): CLI startup failure + startAnnotateServer throw keyed on tailnetPublished, matching how the annotate agent terminal treats tailnet publication. Covered in annotate.test.ts and documented in AGENTS.md. - Keep main's compact-touch input controls and effective mode/input values on the HTML surface while preserving the live pinpoint-only clamps. - Regenerate the pinned guide-viewer manifest (CSS hash moved with the new UI classes; JS unchanged). * feat(live-annotate): Interact/Annotate mode toggle for live app and raw HTML sessions A live app session used to be unusable: the pinpoint capture-phase click handler owned every click, so buttons, checkboxes, inputs, and links never fired. One boolean mode now governs the HTML/live viewer surface: - Interact: the bridge is fully passive. Pinpoint capture, hover outline, drag-selection toolbar, [data-annotate] clicks, and committed-highlight click interception are all gated behind annotateModeActive, so clicks, forms, text selection, and SPA navigation reach the page natively. Committed markers and highlights stay VISIBLE, and marker buttons keep their clicks (a marker click still opens its comment). - Annotate: classic behavior, unchanged. Live sessions annotate exclusively via pinpoint while armed. Control: a single bubble icon button in the editor header (icon never changes; armed = accent + visible border, idle = transparent border of the same width, so the box is pixel-identical in both states), plus a subtle inset accent ring floated over the viewer while armed (pointer-transparent, no layout shift). Keyboard: Mod+Shift+A through the shortcut registry (html-annotate scope; the bridge mirrors the chord inside the iframe and forwards it over the authenticated postToParent path). Esc gains a final ladder rung: draft closes first, then the hover outline clears, then Esc exits Annotate back to Interact (bridge posts annotate-exit; a parent-side listener covers Esc with editor focus). The parent owns the mode and pushes it with the same re-post-on-ready pattern as set-input-method, so it survives live page changes, HMR reloads, and bridge re-injection without ever reloading the iframe. Defaults: live app sessions START in Interact; static/raw HTML sessions START in Annotate (today's behavior preserved, and the srcdoc bridge default keeps behavior byte-identical when no set-annotate-mode ever arrives). Session-only state, no persistence. Vim navigation is available only while Annotate is armed. Covered by new bridge-harness and parent-side DOM tests in htmlLiveProtocol.test.tsx and htmlPinpointProtocol.test.tsx: Interact pass-through, armed capture, the Esc ladder order, mode survival across re-injection, marker clicks in Interact, and both defaults. * feat(live-annotate): pinpoint-armed default, always-on drag comments, comment-only HTML surfaces Simplifies the Interact/Annotate design after live review. The new contract replaces the previous one where they conflict: - BOTH surfaces (raw HTML and live app) now START ARMED with pinpoint; the live-session Interact default is gone. Esc keeps the ladder (close draft, clear hover, then exit to Interact) and the header toggle re-arms. The bridge also paints the pinpoint cursor at init instead of waiting for the parent's first round trip. - The header toggle is a PEN icon: the old bubble sat next to the annotations-panel bubble and the two were indistinguishable. Same box geometry (armed = accent + visible border, idle = transparent border of identical width), aria-pressed, Mod+Shift+A, and the armed ring over the viewer are all unchanged. - Text drag-selection commenting is ALWAYS live on HTML/live surfaces, in BOTH states: the selection pass is ungated from annotateModeActive and from the pinpoint input method. In armed pinpoint, click = pin an element and drag = select text, simultaneously; the >4px drag arming decides which one a gesture was, a completed drag's trailing click never re-pins (one-shot dragEndedClick), and a plain click is never swallowed (the pass only acts on a real selection and never preventDefaults). Esc in Interact still closes an open drag draft before yielding to the page. - HTML/live surfaces are COMMENT-ONLY: useHtmlAnnotation clamps redline/quickLabel (both the host mode and a bridge-posted modeOverride, so a hostile page cannot force a DELETION), the selection toolbar drops Delete and quick labels behind a new commentOnly seam on AnnotationToolbar, and the quick-label picker portal is gone from HtmlViewer. Markdown surfaces keep the full toolbar, and persisted DELETION annotations still restore. - The "Show tools"/"Hide tools" header button is removed. It hid the floating toolstrip (now gone from HTML surfaces entirely: with comment-only plus both input paths live there is nothing left to switch), the collapsed sidebar tab flags, and the viewer's floating action cluster (attachments + global comment + version-diff toggle), all of which are now always visible. htmlChrome persistence keeps only the sidebar/panel state; an old cookie's toolsHidden flag is read tolerantly and ignored, so a stale record cannot strand a user with hidden chrome and no way back. - HTML surfaces pin the viewer input method to pinpoint (the drag/ pinpoint switch is meaningless when both are live); the Alt input switch no-ops there. Vim stays armed-only, as built. No server, proxy, or protocol-security changes; the armed flag stays session-only. Tests: the live-bridge harness is reworked around the armed default (forged-DISARM posture, drag-selection passes in armed and Interact, the trailing-click guard), the pinpoint suite covers the comment-only toolbar and the redline/quickLabel clamp at the trust boundary, a new AnnotationToolbar.commentOnly seam test guards both surfaces' toolbars, App.htmlChrome.test.tsx replaces App.htmlHideTools.test.tsx (no tools button, stale-cookie tolerance, pen armed default), and the htmlChrome tests cover the narrowed persisted shape. * feat(live-annotate): collapsible floating controls cluster The simplification removed the Hide tools toggle, which left the floating comment/attachments cluster permanently over the page. Restore a hide affordance on the cluster itself: a collapse chevron shrinks it to a small expand pill in the same corner, so the page is never obstructed without a way back. Collapsed state persists with the rest of the HTML chrome cookie (sidebar/panel), tolerantly read. Hosts that do not wire the toggle (readOnly viewers, review-editor panels) are unchanged. * feat(live-annotate): header Show/Hide tools replaces the collapse pill The collapse pill was a half measure: it left its own artifact over the page and the sidebar tongue tabs stayed. Revert it and restore the real thing as a header control: an eye toggle immediately left of the pen that removes ALL floating chrome over the page from the DOM (sidebar tongue tabs + the comment/attachments cluster), leaving nothing behind. The toggle lives in the header, so a hidden state always has a way back, which also makes honoring a persisted (or pre-existing) toolsHidden cookie safe again. |
||
|
Michael Ramos
|
d6d727b34f | ci(release): add SBOM and Grype release gate (#1298) | ||
|
Michael Ramos
|
58598bbf2b | ci(security): add isolated ZAP DAST monitoring (#1299) | ||
|
Michael Ramos
|
d4ce3dcb57 |
ci: harden releases and add security scanning (#1274)
* ci: harden release and add security scanning * Harden release and deploy recovery paths * Fix npm artifact pack destinations |
||
|
Michael Ramos
|
9ee2e83287 |
feat(review): make the CallDiff runtime a strictly opt-in, in-UI install (#1270)
* feat(review): make the CallDiff runtime a strictly opt-in, in-UI install
The merged CallDiff integration eagerly installed a ~784MB runtime for
every user at install time, for a feature that is off by default. The
runtime is now strictly opt-in and the opt-in lives in the review UI:
toggle Call flow, click Install in the panel, watch staged progress, and
use the analysis in the same session.
Installers: the default sequence no longer installs the runtime. Opt in
with --with-call-flow (PowerShell: -WithCallFlow),
PLANNOTATOR_INSTALL_CALLDIFF=1, or { "installCallFlow": true } in
config.json (flag > env > config). PLANNOTATOR_SKIP_CALLDIFF_INSTALL is
deleted; --minimal keeps excluding the runtime; the installer prints an
honest note pointing at the in-app install. The headless CLI path
(plannotator install-runtime call-flow) is unchanged.
Server (both runtimes, contract-identical): POST /api/call-flow/install
starts installCallFlowRuntime() in the background via a single-flighted
coordinator (concurrent POSTs join the in-flight install), runs a
Node 22+ preflight before any download (distinct node-unavailable
error), and rejects cross-origin POSTs with 403. GET
/api/call-flow/install-status reports idle/running/done/error with
stage: downloading, verifying, installing-deps, building. Install
completion invalidates the 30s runtime probe cache so the next
capability advert resolves available without a server restart.
Client: the Call flow Dock's runtime-missing state is now the opt-in
funnel with an honest disclosure (about 800 MB on disk, Node 22+,
one-time), staged reduced-motion-safe progress, and error + retry with
a no-node hint. On done the advert is refreshed through
POST /api/review-analysis and the existing available-change refetch
starts the analysis for the current snapshot with no reload. The intro
dialog and Settings toggle note the separate first-use runtime.
Docs: AGENTS.md env table + Review Server API table, marketing
environment-variables / installation / ui-settings / code-review /
api-endpoints pages, and the CallDiff ADR runtime-boundary and server
contract sections.
* test(review): stop leaking PLANNOTATOR_DATA_DIR from the install endpoint tests
The call-flow install endpoint tests overrode PLANNOTATOR_DATA_DIR at
module-eval time and never restored it. bun runs CI's full suite in one
process and evaluates every test file's module before running tests,
while Pi's generated/storage.ts caches its data dir at import time; the
override therefore made storage's cached dir and later files' live
getPlannotatorDataDir() calls disagree, failing the Pi annotate-history
unwritable-dir test and both durable-submit-record tests.
An afterAll restore alone is not enough: it reproduces the same three
failures with the mismatch inverted (storage caches the leaked dir at
module eval, tests then run against the restored one). The env var is
now never touched at module-eval time at all; it changes only inside
tests and is restored to its original value in afterEach, exactly like
the PORT/PATH pattern. The config writes the advert tests persist
through the process's frozen config module are snapshotted at load and
restored in afterAll so a standalone run never flips a real
config.json setting, and the process-global scope of the mock.module
seams is documented.
Regression proof (previously failing in either mismatch direction, now
green in both orderings):
bun test packages/server/call-flow-install-endpoint.test.ts \
apps/pi-extension/server/annotate-history.test.ts \
apps/pi-extension/server/annotate-submission.test.ts
* feat(review): install CallDiff grammars selectively
* fix(review): harden CallDiff worker environment
* fix(review): close CallDiff verification gaps
|
||
|
Michael Ramos
|
3245310aa8 |
feat(review): add optional CallDiff call-flow analysis (#1268)
* feat(review): add optional CallDiff call-flow analysis * fix(review): harden CallDiff integration |
||
|
Michael Ramos
|
2d61b76c44 |
fix: address the three pre-release sweep findings (#1246)
Three real, new-in-range bugs from the free-hunt regression sweep: - The pinpoint anchor builder ran a document-wide uniqueness query per ancestor against a growing selector with no depth cap, so one click on a deeply wrapped document froze the tab synchronously (measured 58s at depth 800). The walk now abandons the anchor past 40 ancestors (fail closed: text-search restoration takes over), bounding the work to interactive time. Regression test uses two identical depth-60 chains so uniqueness cannot short-circuit before the cap. - The 10k selection-text cap sliced UTF-16 code units and could split a surrogate pair at the boundary, silently corrupting the annotation tail into U+FFFD downstream. Both sides of the bridge now back the cut off one unit when it would land mid-pair. - The old-git sparse fallback matched git's "unknown option" error literally, which localized git builds translate, so non-English users on old git hit the exact hard failure #1239 was written to fix. All three installers now pin LC_ALL=C around the probe clone (saved and restored; kept single-line in install.ps1 for the scoped-call scanner, whose expectation is updated to the new prefix). |
||
|
Michael Ramos
|
65b0b739a9 | fix(install): fall back to a plain shallow clone when git lacks --sparse (#1238) (#1239) | ||
|
Michael Ramos
|
9dc816959c |
test(install): give the PowerShell scanner tests room for pwsh cold start (#1227)
The first pwsh spawn in the process pays assembly-load and JIT cost that exceeds bun's 5s default on a loaded CI runner, so whichever scanner test ran first failed with a timeout. It blocked two unrelated PRs today. Warm spawns finish in ~300ms, so the six tests now carry an explicit 60s budget instead of racing the default. |
||
|
Michael Ramos
|
10a5104888 |
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. |
||
|
Michael Ramos
|
7682628db7 |
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. |
||
|
Michael Ramos
|
93b66e0ab2 |
feat(cli): add safe uninstall lifecycle (#1170)
* feat(cli): add safe uninstall lifecycle * fix(uninstall): harden cleanup and add Windows QA * fix(uninstall): detach Windows self-delete worker * fix(uninstall): preserve PowerShell worker syntax * fix(uninstall): harden purge and host recovery * fix(uninstall): revalidate purge boundary * fix(uninstall): unlink managed link entries safely |
||
|
Michael Ramos
|
15bca1390e |
fix(install): stop PowerShell < 7.2 from treating git progress as an error
Under $ErrorActionPreference=Stop with stderr redirected, older PowerShell turns a native command's first stderr line into a terminating error, and git prints its normal "Cloning into ..." progress on stderr, so the skill install failed on the message announcing the clone had started. Scope the two git calls to a local Continue preference; success and failure stay detected by Test-Path and exit codes, never by throws. Reproduced and verified under pwsh 7.1.3 (throws before, survives after; a real clone failure still reports). Fixes #1162. |
||
|
tbontb
|
07c89ff145 |
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> |
||
|
Raúl
|
8042ad07d4 |
fix(install): pass --global to npx skills add so extras do not leak into cwd (#1078)
Apply global scope consistently across the shell, PowerShell, and cmd installers and their public install-later documentation. Add parity coverage so every supported command remains explicitly global. |
||
|
Michael Ramos
|
9ddb87abb4 |
feat(data-dir): fall back to $XDG_DATA_HOME/plannotator when ~/.plannotator does not exist (#1093)
New resolution order for the Plannotator data directory:
1. PLANNOTATOR_DATA_DIR (unchanged, top priority, ~ expansion)
2. ~/.plannotator when it already exists (legacy default — existing
installs never move)
3. $XDG_DATA_HOME/plannotator when XDG_DATA_HOME is set to a
non-empty absolute path
4. ~/.plannotator (default for everyone else)
This is git's legacy-first pattern: the XDG branch only fires for fresh
installs whose user has explicitly set XDG_DATA_HOME. The XDG spec's
implicit ~/.local/share default is deliberately NOT applied, and the
directory stays monolithic (no config/data/cache split).
Mirrored in every private copy of the resolver: the Amp plugin,
scripts/install.sh, scripts/install.ps1, and scripts/install.cmd. The
Pi runtime picks the change up automatically via vendor.sh. Docs updated
in README.md, AGENTS.md/CLAUDE.md, and the marketing env-var reference.
Claude-Session: https://claude.ai/code/session_01YXkgsNucxDwAL4GdR4XYRk
|
||
|
Michael Ramos
|
f14cbf836d | Route legacy docs and blog URLs to Mintlify | ||
|
Michael Ramos
|
47bdd210dc |
fix(install): quote exe path in Windows hook commands; ASCII-purge install.cmd
Adversarial QA findings. (1) install.ps1 and install.cmd spliced the absolute exe path UNQUOTED into the generated hooks.json commands — any Windows user with a space in their profile path (C:\Users\John Smith\...) got hook commands that word-split when the hook shell runs them, so plan review silently never intercepted (install.sh is immune: it writes the PATH-resolved bare name). Both hook commands in both installers now wrap the path in JSON-escaped quotes, pinned by updated harness assertions. (2) install.cmd still carried 32 em-dashes + 2 ellipses — several in user-facing echo lines — which render as mojibake on cmd.exe's default non-UTF-8 codepages; #1021 fixed exactly this class in install.ps1 but left cmd untouched. Full ASCII purge, with a new ASCII-only regression test mirroring the ps1 one. Harness: 85 pass / 0 fail. Claude-Session: https://claude.ai/code/session_01SFy9fY27SA8g5BtotWPi1G |
||
|
Kushida
|
ee28f1a428 | fix: handle Windows install and review edge cases (#1021) | ||
|
Stan
|
762700fa03 |
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> |
||
|
Michael Ramos
|
740d6fb2eb |
Add WebTUI agent panel to annotate mode (#941)
* feat(annotate): add WebTUI agent terminal * feat(annotate): wire WebTUI agent into annotate UI * docs: recap annotate agent terminal work * fix(annotate): harden agent terminal runtime * docs: add annotate agent terminal runtime ADRs * fix(annotate): polish agent terminal integration * fix(ui): preserve comment draft on Ask AI failure * fix(annotate): address terminal review findings * fix(annotate): harden agent terminal runtime fallback |
||
|
Michael Ramos
|
0be4295a2e |
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. |
||
|
Michael Ramos
|
c3ba55e889 |
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. |
||
|
Michael Ramos
|
6754dea8df |
fix(install): Windows prompt timeout + sweep stale OpenCode archive stub (#875)
Two v0.19.28 release-gate follow-ups. 1. install.ps1 prompt timeout: PowerShell prompts had no timeout (only the IsInputRedirected gate), so an attached-but-unattended Windows console (PsExec/provisioner first-run or -Reconfigure) could hang. Added Read-LineWithTimeout (standard KeyAvailable polling) -> same bounded read + safe-"no" fallback install.sh already had; default 30s, PLANNOTATOR_PROMPT_TIMEOUT=0 waits forever. Real humans answer in time; -NonInteractive / redirected runs never prompt; the checkbox picker is only reachable after a bounded "yes", so it can't hang unattended. 2. Sweep stale OpenCode archive stub: the /plannotator-archive removal (#873) cleaned the skill scopes but not the OpenCode commands dir, leaving an npm-postinstall upgrader with a dead plannotator-archive.md (empty no-op). Swept in all three installers' cleanup. install.test.ts: assert the OpenCode stub cleanup (sh/ps1/cmd) and the ps1 prompt timeout. 72 pass. |
||
|
Michael Ramos
|
b19505efd3 |
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. |
||
|
Michael Ramos
|
aac5aacbe8 |
fix(install): restore /plannotator-* bash execution on Claude Code + harden unattended installs (#872)
Follow-up to #850 (unreleased), fixing two pre-release regressions vs v0.19.27. - Claude Code: add apps/skills/claude/* skills using `!`plannotator <sub> $ARGUMENTS`` + allowed-tools + disable-model-invocation, so /plannotator-review|annotate|last| archive auto-run with no permission prompt and pass arguments through — matching the old slash commands. Codex keeps the prose apps/skills/core/*. Installers route ~/.claude/skills <- apps/skills/claude and ~/.agents/skills <- apps/skills/core. - Installers: gate the wizard so an unattended-but-open /dev/tty can't hang (PLANNOTATOR_PROMPT_TIMEOUT, default 30s; timeout/EOF resolves to safe "no"). Don't gate on $CI (explicit --reconfigure/--extras must win). Don't persist timed-out wizard answers as install-prefs. Keep ask_yes_no's read in a tested context so set -e never aborts on a timeout. 72 installer tests pass. |
||
|
Michael Ramos
|
26ca4e0275 |
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
|
||
|
Ashwin John Chempolil
|
6a7fd415a7 |
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> |
||
|
Michael Ramos
|
8c947c5419 |
Add Amp plugin integration (#803)
* Add Amp plugin integration * Use official Amp logo on landing page * Tighten landing agent selector * Default landing selector to Claude Code * Stabilize server ready handoff test * Create ready handoff directory before writing * Stabilize server ready handoff tests * Fix Amp command cancellation and cwd * Preserve Plannotator browser handling for Amp * Fix Amp review edge cases * Add PowerShell installer smoke coverage |
||
|
Hrand Liu
|
e0aee7451b |
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> |
||
|
Michael Ramos
|
7db5e9b8d9 |
Fix Windows Pi shim spawning (#792)
* Fix Windows Pi shim spawning * Fix Pi smoke process cleanup * Kill Windows Pi process trees |
||
|
Lea Fox
|
1b1cefbc2a |
Fix directory name for OpenCode commands (#736)
* Fix directory name for OpenCode commands https://opencode.ai/docs/commands/#:~:text=Create%20markdown%20files%20in%20the%20commands/%20directory%20to%20define%20custom%20commands. I believe an s is missing from the OPENCODE_COMMANDS_DIR path * fix(install): apply same command→commands fix to PowerShell script --------- Co-authored-by: Michael Ramos <mdramos8@gmail.com> |
||
|
Leonardo Reis
|
c0e36138fc | Add Codex install guidance (#720) | ||
|
Leonardo Reis
|
6e3efe8e7d | Update Codex hooks feature flag (#708) | ||
|
Michael Ramos
|
f61bff03ed |
fix: update install.cmd test for visual-explainer skill check
For provenance purposes, this commit was AI assisted. |
||
|
Michael Ramos
|
071083e97d |
chore: bump version to 0.19.13
For provenance purposes, this commit was AI assisted. |
||
|
Michael Ramos
|
1eb561551c |
feat: standalone skills package + HTML render-annotate mode (#687)
Add --render-html flag to plannotator annotate that renders HTML files as-is in an iframe instead of converting to markdown. Includes annotation support via postMessage bridge, sharing via paste service, and theme inheritance from Plannotator's 30+ themes. New skill: plannotator-visual-explainer — wraps nicobailon/visual-explainer with Plannotator theme tokens, extended patterns (timelines, SVG diagrams, code blocks, risk tables, Pierre diffs via CDN), and plan/PR-specific guidance. All three servers (Bun, Pi, OpenCode) support the new flag. |
||
|
Michael Ramos
|
13c667c044 |
feat(hook): PFM reminder & improvement hook support across all runtimes (#689)
PFM reminder & improvement hook support across Claude Code, OpenCode, and Pi. - Add opt-in PFM reminder (pfmReminder config flag) injected on EnterPlanMode - Wire composeImproveContext() into all three runtimes - Fix OpenCode system.transform array reference bug (pushes were going to dead array) - Fix install scripts silently stripping PreToolUse/EnterPlanMode hook entry - Isolated Pi sandbox testing (--no-extensions -e) |
||
|
Michael Ramos
|
f7b55e2e5f |
Avoid Pi bundled skill conflicts
## Summary - configure Pi package entries to keep extension commands while disabling bundled package skills when shared Plannotator skills are installed globally - preserve Pi bundled skills when global shared skills are unavailable - write Pi settings without a UTF-8 BOM on Windows ## Tests - bash -n scripts/install.sh - bun test scripts/install.test.ts - git diff --check |
||
|
Michael Ramos
|
7c6dc142a4 |
Install Plannotator command skills under Codex home (#669)
* Install Plannotator skills under Codex home * Keep shared Plannotator skills in agent scope * Harden scoped skill migration |
||
|
Andrei Ivanov
|
a22a744749 |
Add Codex Stop-hook plan review (#577)
* feat: add codex stop hook plan review * Install Codex plan review hooks * Remove Codex manual test screenshots * Update Codex plan mode docs * Tighten Codex release readiness * Preserve custom Codex hook wrappers * ci: smoke test release artifacts * ci: reduce release smoke flake risk * fix: keep Codex last-message extraction to output text * ci: poll release smoke servers on loopback * ci: skip macOS release smoke jobs --------- Co-authored-by: Michael Ramos <mdramos8@gmail.com> |
||
|
Michael Ramos
|
1338802a58 | Scope OpenCode submit_plan to planning agents (#571) | ||
|
Michael Ramos
|
ed540dd79d |
fix: add OpenCode cache clearing to install.cmd
Windows CMD install script had no cache busting at all — OpenCode users on CMD stayed on stale plugin versions indefinitely. For provenance purposes, this commit was AI assisted. |
||
|
Michael Ramos
|
29fc7920f8 |
chore: bump version to 0.17.5
For provenance purposes, this commit was AI assisted. |
||
|
Michael Ramos
|
ed254cf3bd |
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. |
||
|
Michael Ramos
|
1800c24d80 |
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. |