* fix(ci): build with go1.26.6 to clear the govulncheck gate (BUG-2565)
main has been red since da6ce642 on CI's Go job, at the govulncheck
step — not a test, lint or build failure, and not caused by that commit,
which touches no dependency or toolchain pin. govulncheck reports 8
reachable Go standard-library advisories, all "Found in: net@go1.26.5 /
Fixed in: net@go1.26.6" (GO-2026-5942 via net.Resolver.LookupCNAME,
GO-2026-5026 via http.Client.Do, and friends). A vuln-DB entry published
in the window turned the gate red with nobody committing anything, which
is the failure mode a govulncheck gate has by design. No dependency bump
fixes a stdlib advisory; the toolchain has to move.
Adds `toolchain go1.26.6` rather than raising the `go 1.26.5` directive.
The distinction is load-bearing: every GitHub Actions job here exports
GOTOOLCHAIN=auto explicitly, so all of them fetch 1.26.6 and stamp it
into the binary govulncheck scans, while builders pinned to
GOTOOLCHAIN=local ignore the line and keep satisfying the 1.26.5 floor.
nixpkgs nixos-26.05 still ships go 1.26.5 (verified against the channel's
go/1.26.nix), so raising the floor would have failed the Nix build
outright to buy nothing.
That leaves the Nix-packaged binary on the 1.26.5 stdlib. Not silently:
BUG-2567 tracks it, with the two heavier options (move the channel,
override go in the package) written down and deliberately not taken here.
The GOTOOLCHAIN=auto comments in both workflows now say what they are
protecting — under `local` the build silently falls back to setup-go's
patch and the gate goes red again, and released binaries would ship the
vulnerable stdlib.
Verified: make vuln goes from "affected by 8 vulnerabilities" to "No
vulnerabilities found" (exit 0), and `go version -m` on the built binary
reads go1.26.6, so the mechanism is the stamp and not a scanner quirk.
Build, make lint (0 issues) and go test ./... all green on 1.26.6.
Fixes BUG-2565. Refs BUG-2567.
* fix(ci): give native-smoke the GOTOOLCHAIN override too, per Codex review
Codex round 1, P2, and correct: native-smoke resolves its Go via
`go-version-file: go.mod`, which reads the `go` directive (1.26.5), so
setup-go's GOTOOLCHAIN=local previously had nothing to block and the
override was unnecessary. Adding `toolchain go1.26.6` changes that —
without it this job keeps smoke-testing a 1.26.5 binary on macOS and
Windows while every other job and every release artifact moves to
1.26.6.
Worth fixing precisely because it is not a gate failure. Nothing goes
red; the platform smoke coverage just quietly stops matching what ships,
which is the pins-disagree failure mode this PR exists to avoid rather
than introduce.
Uses the documented Out-File form rather than `>>`: this job runs pwsh,
where redirection encoding is version-dependent and a UTF-16 line in
$GITHUB_ENV is silently ignored.
* fix(ci): drop the redundant native-smoke override, document why (round 2)
Codex round 2 flagged the comment I added in round 1 as stale, and
checking the pinned setup-go source settles it — but not quite the way
the note said, so recording what the code actually does:
parseGoVersionFile (installer.ts) prefers go.mod's `toolchain` directive
over the `go` directive, CONDITIONALLY — only when GOTOOLCHAIN is not
already `local` in the environment at parse time.
In this job it isn't, so setup-go installs go1.26.6 itself and the
override I added does nothing. Removing it rather than keeping a no-op
step whose comment asserts a mechanism that isn't operative — a wrong
explanation in the tree is worse than no explanation, since it is the
part the next person reuses without re-deriving.
Replaced with a comment on the setup-go step covering both halves: why
this job needs no override where its siblings do, and the one way it
regresses silently (a job- or workflow-level `env: GOTOOLCHAIN: local`
added above it would flip the parser back to the 1.26.5 floor while
everything else ships 1.26.6 — no red, just smoke coverage that stops
matching the artifact).
The round-1 finding was still right: before checking, "native-smoke
builds 1.26.5" was the reasonable read.
* ci: make the go test timeout explicit everywhere (TASK-2545)
The v0.13.0 release pre-flight died on `panic: test timed out after
10m0s` in internal/store, on a commit whose Go tree was identical to a
green run an hour earlier. Nothing hung — the package's runtime simply
crossed a budget nobody had chosen.
`go test` without -timeout uses a 10m per-test-binary default. This repo
raised the two RACE steps to 45m twice as the suite grew (BUG-1371 30m,
BUG-1913 30m→45m), each time with a careful comment — and each time left
their non-race siblings on the silent default. Three steps were still
running on it, including the release gate:
ci.yml "Run tests" (SQLite)
ci.yml "Run tests against PostgreSQL" (the one that panicked)
release.yml "Run tests" (the release gate itself)
All three now carry -timeout=45m, matching the race legs so the file has
one number, with comments saying it is a hang-catcher rather than a
performance budget and that job wall-clock is the signal for "the suite
got slow".
Measured at 212d59e7 on a dev box, both drivers, before and after:
PostgreSQL whole suite 4m43s wall; internal/store 280s; server 103s
SQLite whole suite 1m52s wall; internal/server 107s; store 64s
CI runners are roughly 2x slower, which is what put store's PG binary
over 10m. 45m is ~4.5x current CI headroom.
This raises the ceiling; it does not change the slope. internal/store on
PG costs ~0.43s per test in database setup alone (CREATE DATABASE plus a
full migration replay, where the SQLite harness copies a pre-migrated
template — IDEA-1914), so every test added costs PG CI ~0.43s forever
and that package is 99% of the job's critical path. Measured and filed
as IDEA-2550 rather than fixed here: it changes shared test
infrastructure that gates every merge and deserves its own review.
Verified by running the exact post-change commands on both drivers: PG
green in 4m42s, SQLite green in 1m52s, 25 packages each.
Claude-Session: https://claude.ai/code/session_01QGbUKZBAZoWdEgiTNWsXag
* ci: time the Makefile's go test targets too (TASK-2545)
The previous commit said the timeout was explicit "everywhere" and it
wasn't — `make test`, `make test-pg`, and `make check` were all still on
the 10m default. That matters twice over: it's the same trap the commit
is about, and `make test-pg` is the local mirror of the CI leg that
actually panicked, so a developer reproducing the failure would have hit
a different budget than the one they were debugging.
Found by sweeping every `go test` in the repo rather than only the
workflows — which is what the commit message's own claim required and I
hadn't done when I wrote it.
Verified: `make test` green, 25 packages.
Claude-Session: https://claude.ai/code/session_01QGbUKZBAZoWdEgiTNWsXag
* ci: time the nix checkPhase, cap the Go jobs, correct two claims (TASK-2545)
Codex review. No P1s; the two P2s were both right and one of them
catches me stating an explanation I had not checked.
COVERAGE. `nix/package.nix`'s checkPhase runs `go test ./...` on the
default too, and .github/workflows/nix.yml exercises it — a fourth site
after the three workflow steps and the three Makefile targets. Now
timed. Every `go test` invocation in the repo carries an explicit
-timeout; the sweep is `grep -rn "go test"` over workflows, Makefile and
nix, not just the workflows I happened to be looking at.
JOB CAPS. Codex objected that 45m lets a hung binary burn a
release-gating job. Fair, and the real hole was worse: `go` and
`go-postgres` had NO `timeout-minutes`, so they inherit GitHub's 6-HOUR
default. Both now capped at 100m — deliberately above the two 45m test
steps so the per-binary timeout always fires first, because that is the
one that prints the goroutine dump naming the hung test. The cap only
catches a runaway that isn't a single test (wedged service container,
stuck download).
CORRECTIONS to 496f521f's message:
- It said the race steps were raised "twice (BUG-1371 30m, BUG-1913
30m→45m)". BUG-1371 kept 30m and fixed the bcrypt cost that had blown
past it; BUG-1913 made the only 30m→45m change. One raise, not two.
- It said CI runners are "roughly 2x slower, which is what put store's
PG binary over 10m". That does not survive its own arithmetic: 280s
local x 2 is 9m20s, under the budget. What is actually known is that
the CI binary exceeded 10m and the local one takes 280s, so CI is
>2.14x slower on that binary — a lower bound derived from the failure,
not an explanation of it. I have not measured CI's runtime and should
not have written a factor as if I had.
- "Nothing hung" and "cost the cut ~40 minutes" are TASK-2545's findings
from the goroutine dump and the release timeline, not mine. Attributed
rather than restated as my own observation.
The 0.43s per-test setup figure and both driver runtimes are mine, taken
on this box at 212d59e7 and reproducible with the commands in IDEA-2550.
Claude-Session: https://claude.ai/code/session_01QGbUKZBAZoWdEgiTNWsXag
* ci: put the corrections in the file, not only in a commit message (TASK-2545)
Codex's re-review came back with no P1s or P2s and four nits, all the
same shape: the claims I retracted in 4623cae9's COMMIT MESSAGE were
still sitting in the workflow comments. That's the half that matters —
nobody reads a commit message while editing a CI file, and a correction
that lives only in git log is a correction almost nobody receives.
Fixed in place:
- The raise history: BUG-1913 raised 30m→45m once. BUG-1371 kept 30m and
dropped the test-only bcrypt cost that had blown past it. My comment
said "raised twice (BUG-1371, BUG-1913)".
- The pre-existing race-step comment claiming BUG-1371 kept the step
"well under the 30m budget" — contradicted by BUG-1913 having to raise
it later. Reworded to say what each change actually did. Not my text,
but it is wrong in the file I am editing and the next reader inherits
it either way.
- The "~2x slower, which put store over 10m" line, which its own
arithmetic refutes (280s x 2 = 9m20s). Now states the lower bound the
failure actually supports — CI's store binary exceeded 10m, so >2.14x
this box — and names the retracted claim so a reader who saw the old
version knows it was withdrawn rather than lost.
- "so it never fires before they do" on the job caps, which a job-level
timeout cannot promise: it covers setup and every step, not just the
two 45m ones. Now says "in practice", not a guarantee.
Attribution of TASK-2545's own findings (the ~40 minutes, the goroutine
dump showing nothing hung) moved into the comment too.
Claude-Session: https://claude.ai/code/session_01QGbUKZBAZoWdEgiTNWsXag
#896 raised the go.mod floor to `go 1.26.5`, but actions/setup-go's
`go-version: "1.26"` resolves to the newest patch in its manifest
(1.26.4) and unconditionally exports GOTOOLCHAIN=local, so every Go
command fails with "go.mod requires go >= 1.26.5 (running go 1.26.4)".
This broke `go vet`, the PostgreSQL test job, and the e2e "Build pad
binary" step on main and every PR since #896.
Override GOTOOLCHAIN=auto via a step that writes $GITHUB_ENV *after*
setup-go (last-write wins, since setup-go's export is unconditional),
so Go downloads the required toolchain on demand. Applied to all three
Go jobs in ci.yml plus release.yml.
Claude-Session: https://claude.ai/code/session_015yuBJQYfDj95cgX3DaD8SF
* chore(ci): bump Node 20 actions to Node 24 ahead of June 2026 deadline (TASK-1165)
GitHub deprecated Node 20 in Actions runners; the hard cutoff is
June 2nd, 2026. Pre-emptively bumps the three remaining Node 20
holdouts to their latest Node 24 versions, SHA-pinned per the
existing convention:
- actions/setup-node v4.4.0 → v6.4.0 (using: node24)
- actions/upload-artifact v4.6.2 → v7.0.1 (using: node24)
- anchore/sbom-action/download-syft v0.18.0 → v0.24.0 (using: node24)
Breaking-change review (all clear for our usage):
- setup-node v5/v6: only behavioral change is "limit automatic caching
to npm" — we already pass cache: "npm" explicitly. node-version: "24"
+ cache-dependency-path: web/package-lock.json continue to work.
- upload-artifact v5/v6: v5 treats the Node 24 bump as breaking; v6
requires Actions Runner ≥ 2.327.1 (GitHub-hosted runners are
auto-updated, so no concern). Our single-fixed-name failure-only
upload is unaffected.
- upload-artifact v7: adds optional archive: false single-file unzipped
uploads + ESM internals. Our usage (name/path/retention-days) is
unchanged.
- sbom-action 0.18→0.24: minor 0.x bumps; v0.24 release notes
explicitly cite "update to node 24 + deps".
Post-audit: every uses: spec in .github/workflows/ now reports
node24 or composite. No Node 20 actions remain.
Per TASK-1165 verification: this PR touches .github/workflows/release.yml,
so the playbook's RC decision rule (PLAYB-1160 step 1) triggers — the
next release will warrant a vX.Y.Z-rc.1 to confirm the deprecation
annotation is gone before shipping stable.
* chore(ci): cap golangci-lint cache to 1 day to avoid poisoning recurrences (BUG-1624)
PR #635's first CI run failed on 30+ SA5011/SA4023 false positives
against unchanged code; local cold-cache lint reported 0 issues.
Diagnosis: golangci-lint-action's cache stores the prior pass's
resolved issue list, and once a pass writes degenerate results
(analyzer upgrade, plugin reset, sub-package drift), every downstream
restore replays that list verbatim until the cache key rotates.
The cache key hashes go.mod/go.sum/.golangci.yml plus an action-internal
prefix, so in steady state the key is stable for days and the
poisoned content propagates across PRs. Default invalidation is 7 days.
This change cuts it to 1 day. Most runs still hit warm cache (lint
runs back-to-back within hours of each other are common); we
guarantee a daily fresh full pass that overwrites any bad cached
state. Estimated cost: ~30-60s extra on one CI run per day.
Hand-mitigated the immediate occurrence by deleting the two poisoned
cache entries via the GH cache API; rerun then went green. BUG-1624
captures the full diagnosis + alternatives considered.
* chore(ci): cache Playwright browsers to dodge CDN slow-paths (BUG-1625)
PR #635 hit two consecutive 10-minute timeouts on the E2E job, both
dying inside `npx playwright install --with-deps chromium` while
downloading Chrome from cdn.playwright.dev. The apt portion completed
in ~10s; the CDN download hung for ~7 minutes before the
`timeout-minutes: 10` ceiling killed the job.
Same code earlier in the day ran E2E green in 1m07s — it's a CDN
slowness event, not a behavioral regression. But two-runs-in-a-row
timeouts mean the steady state is fragile.
Fix: cache `~/.cache/ms-playwright` per resolved @playwright/test
version. Splits the install step in two:
- Cache miss: `npx playwright install --with-deps chromium` — full
apt + browser download (current behavior).
- Cache hit: `npx playwright install-deps chromium` — apt system
libraries only (~10s); browser binary is already on disk.
Cache key reads the resolved version from package-lock.json so a
Playwright bump auto-invalidates. Pinned to actions/cache v5.0.5
(node24) per the workflow's SHA-pinning convention.
After the first warm run on each Playwright version, the CDN is
out of the critical path; an outage there can only burn one CI run
before steady state recovers. BUG-1625 has the full diagnosis.
When two lightweight tags point at the same commit (v0.4.0 cut on top
of v0.4.0-rc.1 with no intervening commits, per PLAYB-1160), goreleaser's
git-describe-based auto-detection picked the wrong one on the CI runner
and stamped v0.4.0 artifacts with version 0.4.0-rc.1 — they then collided
with the existing RC release-page assets and the workflow aborted with
422 already_exists. Setting GORELEASER_CURRENT_TAG to ${{ github.ref_name }}
bypasses the auto-detection: it's exactly the tag that triggered the run.
Root-cause-fixes the v0.4.0 ship failure and prevents recurrence for any
future RC → stable sequence where the stable tag sits on top of the RC
without an intervening commit.
Bumps all four Node version pins from "22" to "24" together so CI ↔
production stay aligned:
• Dockerfile (production image): node:22-alpine → node:24-alpine
• .github/workflows/ci.yml — Web job + E2E job
• .github/workflows/release.yml — release pipeline
Going to LTS-bound 24 instead of dependabot's proposed 25-alpine,
which hits EOL on 2026-06-01 (~3 weeks from this commit). Going to
24 instead of waiting for 26-LTS (Oct 2026) because 5 months is too
long to sit on the deferred-bumps backlog and 24 is already a year
into LTS-tested production use. Worst case follow-up is one more
trivial Dockerfile bump in October.
Verified:
• Local `docker build --target web-builder` on node:24-alpine
(npm ci + npm run build) — clean, 24s end-to-end
• `make check` — golangci-lint + go test + npm run build +
svelte-check, 0 errors
Closes dependabot/docker/node-25-alpine (PR #209) — closing rather
than rebasing because we're going to 24, not 25.
* feat(release): sign + notarize macOS binaries (IDEA-830)
Adds Developer ID code-signing and Apple notarization to the release
pipeline so users installing via `brew install perpetualsoftware/tap/pad`
or downloading binaries directly no longer hit Gatekeeper's "cannot
verify the developer" warning.
Uses GoReleaser v2's built-in `notarize:` block (Anchore/Quill backend),
which signs and notarizes in-process from the existing ubuntu-latest
runner — no rcodesign install, no macOS runner needed.
Both the .p12 cert and the .p8 App Store Connect notary key are stored
as base64-encoded repo secrets; Quill decodes them in-process. The
notarize block is gated on `MACOS_CERT_P12` being set, so snapshot
builds, fork PRs, and any context where the cert isn't available skip
cleanly without failing.
Verification plan: tag v0.0.1-rc.3, confirm Action goes green end-to-end,
then on a clean Mac run `brew install perpetualsoftware/tap/pad` and
verify `codesign -dv $(which pad)` shows the Developer ID signature and
`spctl -a -t exec -vv $(which pad)` reports "accepted" with the notary
ticket stapled.
* harden(release): isolate npm build from macOS secrets + pin goreleaser
Addresses Codex review findings on PR #278:
MEDIUM — Apple signing secrets were exposed to the npm web build.
The previous `before.hooks` block ran `npm ci && npm run build` inside
the GoReleaser process, which means npm lifecycle scripts and the
SvelteKit build inherited the Developer ID .p12 cert, cert password,
and .p8 notary key from the goreleaser-action's env. Adding a 5-year
signing cert to that environment meaningfully widened the blast radius
of any npm supply-chain compromise.
Fix: move the web build into a dedicated workflow step before the
goreleaser-action invocation. The MACOS_* secrets are scoped only to
the goreleaser env block, so the npm phase no longer sees them.
LOW — GoReleaser binary version was floated as `~> v2`, while every
third-party Action in this workflow is SHA-pinned per the policy at
the top of the file. With Apple signing credentials now in the env, a
compromised or regressed GoReleaser release would carry meaningful
blast radius. Pinned to v2.15.4 (current latest) so bumps go through
explicit review like the rest of the action pins.
No functional change to the signing/notarization itself — same schema,
same gating, same secrets.
* docs(release): document web/build prereq for local snapshot builds
Addresses second-pass Codex review finding on PR #278.
Removing the goreleaser `before.hooks` web build (done in 6f4a52c to
isolate npm from MACOS_* secrets) means `goreleaser release --snapshot`
from a clean checkout now fails with "embed: no matching files found"
because embed.go declares `//go:embed all:web/build` and there's no
longer a hook that auto-populates that directory.
CI is unaffected (the workflow has a dedicated `Build web UI` step), but
contributors testing goreleaser config locally would hit a confusing
error before reaching the part they wanted to validate.
Doc-only fix: extend the existing comment block at the top of
.goreleaser.yaml to point contributors at `make web` (or the explicit
npm commands) as the prerequisite for local snapshot builds. Note that
`make build` and `make install` already handle this automatically.
* harden(release): add concurrency guard + bump goreleaser timeout
Addresses third-pass Codex review findings on PR #278.
Both findings were LOW (no ship blockers) and pre-existing concerns
that the macOS notarize block makes slightly more visible. Folded into
this PR rather than deferring because both relate directly to the
goreleaser invocation we already touched.
LOW #1 — GoReleaser overall timeout was the default 1h, while the
notarize block now allows up to 20m of Apple notary wait time on top
of build + cosign blob-sign + SBOM + multi-arch docker. On a slow
notary day (or first-cert-use latency), that could come close to or
hit the default ceiling. Bumped `release --clean` to
`release --clean --timeout=2h` for comfortable headroom without
burning Action minutes on the happy path (worker exits as soon as
Apple replies).
LOW #2 — No workflow-level concurrency guard. If two `v*` tags landed
close together (rc.3 then rc.4 within a minute), runs would race on
shared mutable outputs: GHCR `:latest`, the homebrew cask in the
separate tap repo, the GitHub Releases page. Added a top-level
concurrency block that serializes all release runs.
Group is intentionally NOT keyed by `github.ref` — different tag names
share the same mutable infrastructure, so we want all release tags to
serialize, not just repeat pushes of the same tag. cancel-in-progress
is false so a queued tag never aborts a release mid-publish, which
could leave GHCR and the brew tap in inconsistent states.
No functional change to signing/notarization itself.
Migrates from xarmian/pad to PerpetualSoftware/pad across the entire
repo and updates the product subtitle to "Collaborate with your AI
agents".
Go module rename
- go.mod: github.com/xarmian/pad → github.com/PerpetualSoftware/pad
- All Go imports updated across cmd/pad, internal/{cli,server,store,
models,collections,items,events,metrics,webhooks} (~130 files)
- Test fixtures with the literal repo slug ("xarmian/pad" in JSON
shapes, SSH/HTTPS git URL strings, workspace_context fixtures)
also updated, including the secondary repo entry
(xarmian/pad-web → PerpetualSoftware/pad-web — pad-web was also
moved to the org per branch context)
Docs / config
- README badges, install instructions, brew tap, Docker image, source
build path, sponsor link (sponsor link kept as personal @xarmian)
- Subtitle: "Project management for developers and AI agents." →
"Collaborate with your AI agents." (README, manifests, web layout
meta, .goreleaser homebrew description)
- CONTRIBUTING.md, SECURITY.md, skills/INSTALL.md
- .goreleaser.yaml: homebrew_casks owner, GHCR image, release github
owner, cosign cert-identity regex, comments
- .github/workflows/release.yml: tap/release comments
- deploy/k8s/deployment.yaml: container image
- docs/deployment.md: clone URL
- web/static/{site.webmanifest,manifest.json}: description
- web/src/routes/+layout.svelte: meta description + og:description
Brew tap path is PerpetualSoftware/tap/pad (CamelCase, matches
GitHub user case). GHCR image is ghcr.io/perpetualsoftware/pad
(lowercased per GHCR's URL normalization). CODEOWNERS @xarmian and
FUNDING.yml github: xarmian intentionally retained — those are the
personal maintainer / sponsor account, separate from the org repo.
Verification: go build ./..., go test ./... (all pkgs pass), web
build, and make install all clean (TASK-844, TASK-845).
* chore: wire HOMEBREW_TAP_GITHUB_TOKEN into release pipeline
The brews block in .goreleaser.yaml targets the separate xarmian/homebrew-tap
repo. Without a token override, goreleaser falls back to the workflow's
GITHUB_TOKEN — which is scoped to xarmian/pad only and cannot push to the
tap repo. At first real tag time the brew publish step would fail with a
permission error.
- Add `repository.token` to the brews block, referencing
`{{ .Env.HOMEBREW_TAP_GITHUB_TOKEN }}`
- Export `HOMEBREW_TAP_GITHUB_TOKEN` from the workflow `secrets` into the
goreleaser step env, alongside the existing `GITHUB_TOKEN`
- Comment both edits with the rationale + the fine-grained PAT permissions
the secret needs (`Contents: write` + `Metadata: read` on the tap repo)
The secret itself is created on the human side (HT-780). Snapshot mode
skips publishing so this isn't testable locally — the gate is HT-782's
v0.0.1-rc.1 dress rehearsal.
Refs: TASK-806, TASK-778 (audit), HT-780 (operator step)
* chore: migrate goreleaser deprecations (archives.formats, dockers_v2, homebrew_casks)
Three v2 deprecations were flagged by `goreleaser check` while wiring the
tap token. Migrating them now (instead of filing tech debt) because we're
already touching the file and these are part of the same release pipeline
that ships at v0.1.0 — no point landing a "wire the token" commit that
still trips deprecation warnings on the very next CI run.
Changes:
- archives: `format: tar.gz` + `format_overrides[].format: zip` →
`formats: ["tar.gz"]` + `format_overrides[].formats: ["zip"]`
(single-string is still accepted but the list form is the new spec)
- dockers + docker_manifests → dockers_v2:
Single block with `images:` + `tags:` + `platforms:` collapses the
prior per-architecture builds plus separate manifest declarations into
one declaration. buildx + multi-platform are implicit. Snapshot
validates: amd64 + arm64 images both build, manifest list assembled,
binary runs inside the cross-built image.
goreleaser flags dockers_v2 as "experimental and subject to change" —
it's the documented forward path for v2 and the project is already
pinned to `version: "~> v2"`, so we're committed to the roadmap.
- Dockerfile.goreleaser: add `ARG TARGETPLATFORM` and update the COPY to
`${TARGETPLATFORM}/pad`. dockers_v2 organizes pre-built binaries under
`linux/amd64/pad`, `linux/arm64/pad` etc; buildx populates
TARGETPLATFORM per platform during the build.
- brews → homebrew_casks: `directory: Formula` → `directory: Casks`.
The `brews` keyword is fully phased out in v2.10+; goreleaser's
homebrew_casks now natively handles pre-compiled binaries (which used
to require workarounds with the old brews block). End-user UX is
unchanged: `brew install xarmian/tap/pad` works identically because
modern Homebrew auto-detects whether a tap entry is a formula or a
cask. Removed the no-op `test:` stanza that doesn't apply to casks.
Validation: `goreleaser check` clean (zero warnings), `goreleaser
release --snapshot --clean --skip=publish,sign,sbom` builds all six
binaries, six archives, one cask, two cross-platform docker images.
`docker run --rm ghcr.io/xarmian/pad:latest-amd64 --version` returns
the snapshot version as expected.
Refs: TASK-806
* chore: bump Go toolchain to 1.26 (TASK-763)
Bump Go from 1.25 to 1.26 across all toolchain pins:
- go.mod — go 1.25.0 → go 1.26.0
- Dockerfile — golang:1.25-alpine → golang:1.26-alpine
- .github/workflows/ci.yml — three setup-go steps (Go, Go-Postgres, E2E jobs)
- .github/workflows/release.yml — release pipeline
No `toolchain` directive: the repo is pre-launch with no external
contributors yet, so we set the floor where we want it (hard requirement).
Verified locally before commit:
- golangci-lint v2.11.4 builds and runs under Go 1.26.2 (pinned in CI)
- golang:1.26-alpine and 1.26.2-alpine images present on Docker Hub
- go build ./... clean
- go vet ./... clean
- go test ./... all pass
Parent: PLAN-644 (OSS Repo Hygiene and Launch Polish).
* chore: gofmt -w under Go 1.26 (TASK-763)
Apply Go 1.26's gofmt to the codebase. ~41 files reformatted, all
struct-tag whitespace realignment — no semantic changes. Verified:
- gofmt -l ./cmd ./internal returns empty after
- go build ./... still clean
- go test ./... still passes (run before commit)
Bundling the gofmt diff with the toolchain bump in the same PR because
the formatting drift is a direct consequence of moving from 1.25 to
1.26; splitting them creates a mandatory two-PR ordering for no value.
Parent: PLAN-644.
* docs: bump documented Go floor to 1.26 (TASK-763)
Match go.mod's hard 1.26.0 requirement in the source-build instructions.
Caught by Codex review round 1 on PR #247.
- README.md:158 — "Go 1.25+" → "Go 1.26+"
- CONTRIBUTING.md:9 — "Go 1.25+" → "Go 1.26+"
Matches the security-posture promise in SECURITY.md and README. Every
GA release will now publish:
- Signed checksums.txt (Sigstore keyless cosign via GitHub OIDC)
- Signed container manifests for ghcr.io/xarmian/pad (cosign sign)
- SPDX SBOM (.spdx.json) next to each archive (syft via goreleaser
sboms: section)
- SLSA v1 build provenance attestation for every archive via
actions/attest-build-provenance
.goreleaser.yaml:
- Add sboms: (artifacts: archive, SPDX JSON)
- Add signs: for checksum artifact with --output-certificate /
--output-signature
- Add docker_signs: for container manifests
- Fix pre-existing v2 incompatibility in before.hooks (map-with-cmd
form is rejected in v2; switched to the plain-string form required
by the v2 schema — the existing config never validated)
.github/workflows/release.yml:
- Grant id-token: write (required for cosign keyless OIDC) and
attestations: write (required by attest-build-provenance)
- Install cosign (sigstore/cosign-installer v3.10.1) before goreleaser
- Install syft (anchore/sbom-action/download-syft v0.18.0) before
goreleaser
- Add actions/attest-build-provenance (v4.1.0) step after goreleaser
to mint SLSA provenance for all built archives
All new actions pinned to 40-char SHAs per the existing pinning
convention. Verified with:
docker run goreleaser/goreleaser:v2.15.4 check # config valid
yq -e '.' .github/workflows/release.yml # YAML valid
Parent: PLAN-644.
Every third-party Action in .github/workflows/ was using a floating
tag (@v4, @v5, @v6). A compromised maintainer — or a tag that gets
re-pointed at a malicious commit — could execute attacker code in CI
with contents:write, packages:write, and the GHCR token in scope.
Release.yml is especially exposed: a compromised step there could
publish tampered binaries to GitHub Releases and GHCR.
All 12 'uses:' references now pin to a 40-char commit SHA with a
trailing '# vX.Y.Z' comment (the comment is what humans read during
review; the SHA is what GitHub actually resolves):
actions/checkout@34e114876b # v4.3.1
actions/setup-go@40f1582b24 # v5.6.0
actions/setup-node@49933ea528 # v4.4.0
docker/setup-buildx-action@8d2750c68a # v3.12.0
docker/login-action@c94ce9fb46 # v3.7.0
goreleaser/goreleaser-action@e435ccd777 # v6.4.0
Version bumps: pin to the newest release within the same major that
was previously in use (so behavior stays the same — no major version
jumps hidden inside a security PR). Dependabot (incoming in TASK-678)
will track the commit-pinned refs and open PRs that update both the
SHA and the version comment together.
Parent: PLAN-644.
- README: update agent integration section to show pad install with all supported tools
- README: add pad install step to Quick Start
- Release workflow: add web build placeholder before go test to prevent embed failure
Pad — project management for developers and AI agents.
Single Go binary with embedded SvelteKit web UI, SQLite storage,
CLI, and Claude Code /pad skill integration.
https://getpad.dev
dependabot[bot]