xarmian c67c167c43 feat(backlinks): title-form wiki-links + rename cascade (Phase 2a) (#621)
* feat(backlinks): title-form wiki-links + rename cascade (Phase 2a)

Phase 2a of PLAN-1593 (TASK-1595). Extends the server-side wiki-link
reverse index from Phase 1's `[[REF-N]]` coverage to also handle
`[[Title]]` and `[[collection/Title]]`. Cross-workspace `[[ws::REF]]`
forms stay gated until TASK-1597 (Phase 2b) ships the request-
independent ACL helper.

What changed
- internal/links/extract.go: lift the Phase-1 emit gate for
  WikiLinkKindTitle; keep WikiLinkKindWorkspaceRef gated.
- internal/store/wiki_links.go: title branch in replaceWikiLinks
  (verbatim target_title storage + case-insensitive resolution),
  resolveTitleTx with full-key match first / `/`-split fallback
  (mirrors renderer order — Codex review caught the inverse on the
  planning round), cascadeTitleRename + resolveBrokenTitleLinks.
- internal/store/items.go: rename cascade fires in-tx on title
  change; create path flips pre-existing broken title rows.
- internal/store/migrations/062 + pgmigrations/041: one-shot
  `DELETE FROM item_wiki_links` so the startup backfill repopulates
  with the Phase 2a vocabulary.
- Tests cover title round-trip, case-insensitive resolution, broken-
  link persistence + later resolution, full rename cascade with
  content rewrite, collection-qualified form, full-key-beats-split
  precedence (regresses Codex finding #3), broken-row flip on rename,
  no-op rename, and self-reference filtering.

PLAN-1593 / TASK-1595.

* fix(backlinks): rename cascade preserves display aliases (Codex round 1)

Codex round 1 against PR #621 caught: the title-rename cascade
selects sources via target_item_id (correctly hitting all rows that
resolve to the renamed item — including aliased and mixed-case
shapes), but the literal `strings.ReplaceAll` rewrite step only
matched `[[Old Title]]` / `[[<slug>/Old Title]]`. Rows from
`[[Old Title|alias]]`, `[[old title]]` (mixed case), or
`[[<slug>/Old Title|alias]]` slipped past the rewrite; the trailing
replaceWikiLinks re-parse then saw the same body, failed to resolve
under the new title, and converted the row to broken — exactly the
regression the cascade exists to prevent.

Fix: new internal/links/RewriteWikiTitle helper handles all four
title-form shapes with case-insensitive title matching and verbatim
display-alias preservation. Cascade swaps from ReplaceAll to this
helper. Unit tests in links_test.go cover the matrix; integration
test in wiki_links_test.go regresses the original failure mode by
mixing all four shapes in one source and asserting all four stay
resolved after rename.

Known limitation documented in the helper: titles containing wiki-
link escape characters (`]`, `|`, `\`) — stored escaped in source
content — don't match the regex's literal old-title segment. Same
limitation exists in the legacy ReplaceTitle helper; promotable if
a real user hits it.

PLAN-1593 / TASK-1595.

* fix(backlinks): retarget qualified-fallback rows on literal-title arrival (Codex round 2)

Codex round 2 against PR #621 (P2): resolveBrokenTitleLinks only
flipped target_item_id IS NULL rows, missing the arrival-order case
where a literal `[[tasks/Setup]]` should win stage 1 over a row
previously resolved via stage 2 (qualified fallback to item "Setup"
in collection "tasks"). The index would stay stale until the source's
content was rewritten — a latent inconsistency between the persisted
backlink and what the renderer would actually show.

Fix: drop the IS NULL constraint on the stage-1 UPDATE. Stage 1
ALWAYS wins per the renderer's order at markdown.ts:541, so any row
with a matching literal title flips to the new item — including
rows currently pointing at a qualified-fallback target. Added a
target_item_id != ? guard so we don't churn rows that already point
at us. Stage 2 keeps the NULL constraint so already-resolved
qualified rows don't churn when another fallback candidate appears.

Regression test in wiki_links_test.go reproduces the exact scenario
Codex described: fallback resolves first, literal arrival steals the
row from the fallback target.

PLAN-1593 / TASK-1595.

* fix(backlinks): renderer parity for [[A|B]] + scope arrival retarget (Codex round 3)

Two findings from Codex round 3 against PR #621:

P1 — parser/renderer parity for [[A|B]] matching literal title "A|B".
The renderer (web/src/lib/utils/markdown.ts:516-525) tries the FULL
body as a title FIRST when a pipe is present, only falling through
to the split interpretation on miss. Our parseBody always split on
the first unescaped pipe, so an item literally titled "A|B" was
indexed as title="A" with display="B" — the index would miss
backlinks the UI shows, or point them at a different "A" item.

Fix: in replaceWikiLinks for title kind, when HasDisplay, try the
full body (Title+"|"+Display) as a title FIRST via resolveTitleTx;
on hit, store target_title=fullBody and drop the display override
(the display segment was actually part of the title). On miss, fall
back to the existing split-key interpretation. The cascade's
RewriteWikiTitle regex correctly handles both storage shapes via
QuoteMeta on the title.

P2 — stage-1 UPDATE was too aggressive after the round-2 fix. The
broad UPDATE (no IS NULL constraint) silently stole backlinks from
legitimately-resolved rows when a SECOND item was created/renamed
to the same title. Titles aren't unique, the renderer's
Array.find() is order-dependent, and silent churn is worse than
no-op stability.

Fix: split resolveBrokenTitleLinks into three updates:
  (1) Plain literal flip — NULL only.
  (2) Qualified literal flip — NULL only.
  (3) Literal-arrival retarget — gated on title containing `/`.
      Only fires for `[[<slug>/Title]]` rows, which are the only
      ones that COULD have been stage-2 qualified-fallback
      resolved. Rows with target_title='Foo' (no slash) can only
      have been stage-1 literal — we don't steal those.

Regression tests:
- TestWikiLinks_LiteralPipeInTitleResolves — `[[A|B]]` resolves to
  item literally titled "A|B".
- TestWikiLinks_LiteralPipeInTitleFallsThroughToSplit — `[[A|B]]`
  falls back to item "A" when no "A|B" item exists.
- TestWikiLinks_SecondItemSameTitleDoesNotStealBacklinks — adding a
  second "Foo" item doesn't redirect the existing backlink.

PLAN-1593 / TASK-1595.

* fix(backlinks): broken pipe-in-body rows keyed on full body (Codex round 4)

Codex round 4 against PR #621: when a source body `[[A|B]]` is
written before any matching item exists, the broken row was stored
with target_title="A" (the split key). If an item literally titled
"A|B" was later created, resolveBrokenTitleLinks looking for
target_title="A|B" couldn't find the row — index went stale while
the renderer's preferred full-body interpretation would correctly
resolve the link.

Fix: when nothing resolves AND a pipe was present (HasDisplay), key
the broken row on the FULL body (Title+"|"+Display) instead of the
split key. resolveBrokenTitleLinks then naturally finds it via the
literal-arrival path.

The remaining asymmetry — a broken row keyed on full body won't pick
up a future split-fallback resolution to a new item titled "A" — is
documented in the code as a v3-promotable limitation. The full-body
path is the renderer's PREFERRED interpretation (markdown.ts:516),
so prioritizing it is the right tradeoff in the rare case both
interpretations could apply.

Regression test in wiki_links_test.go reproduces the scenario:
source written first with `[[A|B]]`, item titled "A|B" created
later, backlink should resolve.

PLAN-1593 / TASK-1595.

* fix(backlinks): scope stage-3 retarget + cascade self-refs (Codex round 5)

Two findings from Codex round 5 against PR #621:

Finding 1 — stage-3 literal-arrival retarget could still steal
backlinks from a legitimate stage-1 literal-match row when a SECOND
item with the same slash-containing title is created. The previous
fix (round 3) gated stage-3 on title containing `/`, which let
through the qualified-fallback retarget case correctly but didn't
distinguish stage-1-resolved rows pointing at a literal twin from
stage-2-resolved rows pointing at the fallback target.

Fix: add an EXISTS check that scopes the flip to rows whose CURRENT
target has a title NOT matching ours. Stage-1 (literal) resolutions
point at items literally titled the same as the row's target_title;
stage-2 (qualified-fallback) resolutions point at items titled just
the trailing segment. The EXISTS clause picks out only the latter.

Finding 2 — self-references on the renamed item went stale on
title-only renames. The cascade's `s.id != renamedItemID` filter
excluded self, but items.go only re-indexes content when
input.Content != nil. So a title-only rename of an item whose body
mentions itself by its old title kept the body's now-broken
`[[Old Title]]` literal in place while the index still recorded a
"working" backlink — drift between renderer state and index state.

Fix: drop the self-exclusion from the cascade SELECT. RewriteWikiTitle
rewrites the renamed item's own content along with everyone else's;
GetBacklinks still hides self-links at query time, so the backlinks
panel behavior is unchanged.

Tests:
- TestWikiLinks_DuplicateSlashTitleNoTheft regresses Finding 1.
- TestWikiLinks_TitleRenameRewritesSelfReferences asserts Finding 2's
  new correct behavior (replaces the prior test that asserted the
  old buggy behavior).

PLAN-1593 / TASK-1595.

* fix(backlinks): ref→title fallback + reorder cascade self-ref (Codex round 6)

Two findings from Codex round 6 against PR #621:

Finding 1 — ref-shaped title fallback missing. parseBody returns
WikiLinkKindRef for `[[ISO-9001]]` (matches refPattern), but if no
ISO-9001 ref-item exists, the renderer falls through to legacy
title lookup (markdown.ts:513) and resolves to an item literally
titled "ISO-9001". The store inserted only a broken ref-kind row
with target_title=NULL, so GetBacklinks never surfaced the backlink
even when the renderer rendered it.

Fix: in replaceWikiLinks' WikiLinkKindRef branch, when resolveRefTx
misses, try resolveTitleTx on the same body. If title resolves,
INSERT as title-kind row with target_title=ref-shaped-body. The
rename cascade catches these correctly via target_kind='title' +
target_item_id. The asymmetry — a future ref-item creation can't
auto-retarget these title-stored rows — is documented as a v3
limitation.

Finding 2 — combined title+content update broke self-ref cascade.
The original order (main UPDATE → replaceWikiLinks(self) → cascade)
wiped self's `target_item_id=renamedItemID` row before cascade ran:
when input.Content contains `[[Old Title]]`, re-indexing self
resolved it as broken (target_item_id=NULL), so cascade's SELECT
missed self for the title+content path.

Fix: reorder so cascade runs BEFORE the self re-index — the
pre-existing wl rows are still intact at cascade time. The final
re-index re-reads items.content from the DB (since cascade may
have rewritten it in-band) rather than using *input.Content
directly; otherwise the re-index would undo the cascade's
self-ref rewrite.

Tests:
- TestWikiLinks_RefShapedFallsThroughToTitle — `[[ISO-9001]]`
  resolves to an item titled "ISO-9001".
- TestWikiLinks_TitleAndContentRenameCascadesSelfRef — combined
  title+content rename with self-ref in new content gets the
  self-ref rewritten by cascade.

PLAN-1593 / TASK-1595.

* fix(backlinks): ref+pipe→title parity, position-based cascade, scoped self-rewrite (Codex round 7)

Three intertwined fixes addressing Codex round 7 findings against
PR #621:

Finding 1 — ref→title fallback missed pipe-bodies. For
`[[ISO-9001|Spec]]`, renderer tries full-body title "ISO-9001|Spec"
BEFORE falling to bare "ISO-9001" (markdown.ts:516). Our
ref-fallback only tried bare. Extended ref-branch's fallback to
try full body first when HasDisplay, then bare — same order as
the title-branch's stage (a)/(b) pattern.

Finding 2 — cascade corrupted UNRELATED literal-pipe titles. Items
A "Old Title" and B "Old Title|alias" both referenced from one
source; renaming A previously triggered RewriteWikiTitle's regex
`(?i:Old Title)((?:\|...)?)` which matched BOTH A's `[[Old Title]]`
AND B's `[[Old Title|alias]]` — corrupting the B link.

Refactored cascadeTitleRename to be POSITION-BASED: SELECT each
individual wl row with its position + target_title (no longer
DISTINCT sources). Per-row, rewrite the bracket AT THAT EXACT
POSITION via new links.RewriteBracketAt helper. Process rows in
descending position order per source so earlier offsets don't
shift. Brackets whose wl row doesn't resolve to the renamed item
are never visited.

Scoped self-rewrite — title-only renames cascade self
(input.Content == nil); combined title+content renames EXCLUDE
self (input.Content != nil). User-supplied content is
authoritative; auto-rewriting their just-submitted brackets would
surprise them. Mirrors documents.go::updateLinksInTx, which also
leaves the renamed entity's own content alone. Codex round 6
finding 2 is fully addressed: title-only path still rewrites
self-refs, combined path respects user submission and the index
correctly records the bracket as broken (matching what the
renderer would render).

New links.RewriteBracketAt helper with full unit-test coverage:
plain/aliased/qualified/qualified+aliased shapes, case-insensitive
matching, slug-prefix preservation, full-body vs split-key target
disambiguation, out-of-bounds defensive guards. Integration test
TestWikiLinks_CascadeDoesNotCorruptLiteralPipeNeighbor reproduces
Codex round 7 finding 2's scenario.

PLAN-1593 / TASK-1595.

* fix(backlinks): retarget rows pointing at soft-deleted targets (Codex round 8)

Codex round 8 P2: resolveBrokenTitleLinks only considered
target_item_id IS NULL rows as eligible for flip. A row that
resolved to item A and then had A soft-deleted stayed pointing at
deleted A; creating a new item B titled the same as A wouldn't
flip the row, so GetBacklinks(B) missed the backlink the renderer
would actually show (renderer hides deleted-target links).

Fix: introduce a "broken-in-practice" predicate
  (target_item_id IS NULL
   OR NOT EXISTS (
       SELECT 1 FROM items t
       WHERE t.id = item_wiki_links.target_item_id
         AND t.deleted_at IS NULL
   ))
applied to stages 1 (plain literal flip) and 2 (qualified literal
flip). Stage 3 (slash-title literal-arrival retarget) already
considered "current target deleted" implicitly via its title-
mismatch EXISTS check.

Regression test in wiki_links_test.go covers the exact scenario:
A "Foo" resolves a backlink → A soft-deleted → B "Foo" created →
backlink flips to B.

Known limitation deferred to v3: the symmetric case (delete A
while B with same title already exists) doesn't fire any hook
that re-resolves the row. A dedicated DeleteItem hook would close
that gap; not blocking Phase 2a.

PLAN-1593 / TASK-1595.

* fix(backlinks): preserve title whitespace to match renderer (Codex round 9)

Codex round 9 P2: parseBody trimmed whitespace from the body BEFORE
deciding it was a title kind. The renderer doesn't trim before title
matching (markdown.ts:541-543) — `[[ Foo ]]` is matched against
items.title with the surrounding spaces intact, so an item titled
"Foo" wouldn't match. Trimming server-side created index entries
the UI couldn't click — backlinks showed in the panel for links
that the renderer rendered as broken.

Fix: keep an UNTRIMMED unescaped body for title-kind fallthrough,
and a trimmed copy only for ref / workspace_ref SHAPE detection
(refs are whitespace-free by construction, the renderer's
key.trim() at L503 is just typing forgiveness for the ref form).

Tests in extract_test.go:
- `[[ Foo ]]` emits title-kind with Title=" Foo " (whitespace preserved).
- `[[ TASK-5 ]]` still parses as ref (shape detection trims).
- `[[Project  Goals]]` (two spaces inside) preserves internal whitespace.

PLAN-1593 / TASK-1595.

* fix(backlinks): ref→title fallback uses raw untrimmed key (Codex round 10)

Codex round 10 P2: after round 9's title-kind whitespace fix, the
ref→title FALLBACK path still used canonical-trimmed link.Ref for
its title lookup. The renderer's fallback at markdown.ts:541-543
uses the UNTRIMMED key (no .trim() on the title-lookup path), so
`[[ TASK-5 ]]` falling through to title would search " TASK-5 "
(with whitespace) — an item literally titled " TASK-5 " resolves
in the UI but not in our index.

Fix: add a RawKey field to WikiLinkRef capturing the untrimmed
unescaped key for ref kinds. parseBody populates it alongside the
canonical Ref. replaceWikiLinks' ref→title fallback path uses
RawKey (with defensive fallback to Ref for old rows) when
constructing title candidates. Mirrors the renderer's untrimmed
title lookup across both bare and pipe forms.

Regression test in wiki_links_test.go covers the exact scenario:
item titled " TASK-5 " (with whitespace), source body `[[ TASK-5 ]]`,
backlink resolves via the untrimmed ref→title fallback.

PLAN-1593 / TASK-1595.
2026-05-24 12:01:05 -04:00
2026-03-26 01:52:36 +00:00
2026-03-26 01:52:36 +00:00

Pad

Project Management for the agent era.

CI Release Go Report Card Container image on GHCR License GitHub Sponsors

Website  ·  Docs  ·  Blog  ·  Changelog  ·  X  ·  Bluesky


One binary. Local-first. No accounts required. Pad gives you a CLI, a web UI, and an AI agent skill — all backed by SQLite, all running on your machine. Your project data never leaves your laptop.

Pad dashboard showing collection summaries, active work, an active plan with progress, and a recent activity feed

Quick Start

brew install PerpetualSoftware/tap/pad
cd your-project
pad init                    # configure, auth, workspace, AI skill — all in one
pad server open             # opens the web UI at localhost:7777

pad init is the smart entry point — it auto-detects what's needed, walks you through each step, and is safe to re-run anytime (it skips finished steps and prints a status summary).

Then, in a fresh agent session in your project, say:

/pad onboard

Your new workspace ships with the canonical onboard playbook auto-activated. The agent walks an interview, inspects your codebase if it has shell access, and adapts your workspace's collections, conventions, roles, and playbooks to match the project. It's the fastest way to go from empty workspace to "okay, this is mine."

Why Pad?

Tools like Linear, Jira, and Notion are built for teams on the cloud. Pad is built for developers on their machine — and for the AI agents working alongside them.

Pad Linear / Jira Notion
Setup pad init Create account, invite team, configure Create account, pick template
AI agents Native /pad skill for 7+ tools Third-party integrations Third-party integrations
Data Local SQLite, you own it Their cloud Their cloud
Offline Full functionality Read-only cache at best Limited
CLI First-class Afterthought None
Price Free, open source Per-seat pricing Per-seat pricing

Features

For Developers

CLI that doesn't get in your way. Create tasks, search items, check status — without leaving the terminal.

pad item create task "Fix OAuth redirect" --priority high
pad item create idea "Real-time collaboration" --category infrastructure
pad item list tasks --status in-progress
pad item search "authentication"
pad project dashboard                   # Project dashboard
pad project next                        # What should I work on?
pad server info                         # How this client is connected to Pad

Web UI that stays out of your way. A clean, dark-themed interface at localhost:7777 with:

  • Board, list, and table views — drag-and-drop between status columns
  • Keyboard navigationj/k to move, Enter to open, Esc to go back, Cmd+K to search
  • Rich text editor — Tiptap-based with markdown, formatting toolbar, and auto-save
  • Wiki-links — type [[Title]] to link between items
  • Real-time updates — agent creates a task in the terminal, it appears in the browser instantly (via SSE)
  • Dashboard — collection overview, active work, plan tracking, activity feed

Pad tasks board view: kanban columns for Open, In-Progress, Done, Cancelled with task cards in each

For AI Agents

Your agent becomes a project partner. Install the /pad skill once, and your AI coding tool can read, create, and update project items through natural language.

pad agent install        # Auto-detects your tools and installs the skill

Works with Claude Code, Cursor, Windsurf, Codex, GitHub Copilot, Amazon Q, and JetBrains Junie.

Then just talk to your project:

> /pad what should I work on next?
> /pad I finished the OAuth fix
> /pad create a task to add rate limiting
> /pad let's brainstorm about the API redesign

Conventions and playbooks teach agents how your project works:

  • Conventions — trigger-based rules like "run tests before marking a task done" or "use conventional commits"
  • Playbooks — multi-step workflows like "when implementing a feature: read the spec, create a branch, write tests first, then implement". Playbooks can declare a kebab-case invocation_slug so users can invoke them directly: /pad ship PLAN-42, /pad release 0.5.0. Fresh startup workspaces ship a generic ship playbook out of the box.
pad item create convention "Run tests before completing tasks" \
  --field trigger=on-task-complete \
  --field scope=all \
  --field priority=must

Agents load relevant conventions automatically. All agent actions are attributed in the activity feed, so you always know what the AI changed.

Onboard agents to a new codebase:

Open an agent session in the workspace directory and run /pad onboard. The agent walks an interview, detects your build/test/CI tooling, and adapts your workspace's collections, conventions, roles, and playbooks to match the project. Works for any agent that speaks Pad — Claude Code, MCP-only agents, etc.

Collections & Custom Fields

Pad organizes work into collections — typed containers with structured fields.

Built-in collections:

Collection Purpose
Tasks Work items with status, priority, assignee, effort, due date
Ideas Feature ideas with impact and category
Plans Project milestones with progress tracking
Docs Documentation, decisions, reference material
Conventions Project rules that guide agent behavior
Playbooks Multi-step workflows for agents to follow

Create your own with typed fields — select, text, date, number, url, relation, checkbox:

pad collection create "Bug Reports" \
  --fields "severity:select:low,medium,high,critical; browser:text; reproducible:checkbox"

Items get reference numbers automatically (TASK-5, BUG-12) and can be moved between collections with field migration.

Installation

Homebrew (macOS and Linux)

brew install PerpetualSoftware/tap/pad

Build from Source

git clone https://github.com/PerpetualSoftware/pad
cd pad
make build
cp pad ~/.local/bin/   # or /usr/local/bin/

Requires Go 1.26+ and Node.js 22+.

The go install github.com/PerpetualSoftware/pad/cmd/pad@latest path is not supported for the full Pad binary, because the web UI must be built and embedded during the source build.

Docker

docker run -p 127.0.0.1:7777:7777 -v pad-data:/data ghcr.io/perpetualsoftware/pad

This publishes Pad to localhost:7777 on the host machine, which is the recommended default for local use.

Single user, more than one device? Publish to all interfaces so you can reach Pad from your phone, tablet, or another machine on the same LAN, Tailscale network, or home VPN:

docker run -p 7777:7777 -v pad-data:/data ghcr.io/perpetualsoftware/pad

For multi-instance deployments, Pad supports Postgres + Redis via docker-compose.yml — see docs/deployment.md for the full setup.

Binary Download

Pre-built binaries for macOS, Linux, and Windows are available on the releases page.

Getting Started

1. Set up Pad

cd ~/projects/myapp
pad init "My App"

pad init is the smart entry point that handles everything in one command:

  • Configures this client's connection (local server, remote, or Docker)
  • Auto-starts the local server
  • Creates the first admin account on a fresh local install (Docker / remote hosts run pad auth setup on the server instead)
  • Logs you in if needed
  • Creates or links a workspace for the current directory (writes .pad.toml)
  • Installs the /pad skill for any AI tools detected in the project

Run from your project root. Safe to re-run anytime — it skips finished steps and prints a status summary if nothing's needed.

Choose a template with --template, or omit it for an interactive picker grouped by category (Software / People / …):

pad workspace init --list-templates                   # See the full catalog grouped by category
pad init "My App" --template scrum                    # Scrum-style with sprints
pad init "My App" --template product                  # Product management focused
pad init "My Hiring" --template hiring                # Company-side: requisitions, candidates, interview loops, feedback
pad init "Job Search" --template interviewing         # Candidate-side: applications, interviews, companies, contacts

Pad ships templates for software (startup / scrum / product), people workflows (hiring, interviewing), and has reserved categories for research, content, operations, and personal use so the same project-management primitives fit well beyond code projects.

2. Start working

# From the CLI
pad item create task "Set up CI pipeline" --priority high
pad item create idea "Add WebSocket support" --category infrastructure
pad project dashboard

# From the web UI
pad server open              # Opens localhost:7777 in your browser

# From your AI agent
# Just use /pad in Claude Code, Cursor, etc.

3. Teach your agents the rules

In an agent session inside the workspace:

/pad onboard

The agent walks an interview, detects your tooling, and adapts the workspace's collections, conventions, roles, and playbooks. To browse the library directly:

pad library list --type conventions  # Pre-built conventions you can adopt
pad library list --type playbooks    # Pre-built multi-step workflows

4. Optional — connect a desktop AI app via MCP

Pad ships an MCP (Model Context Protocol) server so Claude Desktop, Cursor, or Windsurf can manage items, plans, ideas, and dependencies as native tools, read workspace state by URL, and load multi-step workflows as prompts.

pad mcp install claude-desktop   # or: cursor, windsurf, --all
# Restart the client; pad shows up as the "pad" MCP server.

Tool catalog (v0.4) — eight resource × action tools plus pad_set_workspace (nine total), no flat verb explosion:

Tool Actions
pad_item create, update, delete, get, list, move, link, unlink, deps, star, unstar, starred, comment, list-comments, bulk-update, note, decide
pad_workspace list, members, invite, storage, audit-log
pad_collection list, create, update, delete
pad_project dashboard, next, standup, changelog
pad_role list, create, update, delete
pad_search query
pad_playbook list, get, run
pad_meta server-info, version, tool-surface, bootstrap
pad_set_workspace session-default workspace pinning (response embeds the bootstrap blob)

Plus resources at pad://workspaces, pad://workspace/{ws}/dashboard, pad://workspace/{ws}/items, pad://workspace/{ws}/items/{ref}, pad://workspace/{ws}/collections, pad://workspace/{ws}/bootstrap, and pad://_meta/version.

Stability contract — two version constants, both advertised in the initialize handshake under capabilities.experimental.padCmdhelp and capabilities.experimental.padToolSurface (and queryable at pad://_meta/version):

  • cmdhelp_version: "0.1" — CLI help-tree contract (used at dispatch time)
  • tool_surface_version: "0.4" — MCP tool catalog contract (PLAN-1410 trimmed the bootstrap-response shape by ~40%; see internal/mcp/version.go for the full v0.4 changelog)

External agents pin against these so a future rename doesn't break them silently. Errors come back as structured envelopes ({error: {code, message, hint, available_workspaces, ...}}) with a closed eight-code taxonomy.

Full guide at getpad.dev/mcp/local — install paths, action enums per tool, error taxonomy, troubleshooting.

CLI Reference

pad auth configure                    Configure how this client connects to Pad
pad auth setup                        Initialize the first admin account
pad auth login                        Sign in
pad auth whoami                       Show current user

pad server start                      Start the Pad API server
pad server stop                       Stop the Pad server
pad server info                       Show client, connection, and local server status
pad server open                       Open web UI in browser

pad workspace init [name]             Initialize workspace in current directory
pad workspace link <workspace>        Link current directory to an existing workspace
pad workspace list                    List all workspaces
pad workspace switch <workspace>      Switch active workspace
pad workspace context                 Show structured workspace context
pad workspace context set --file X    Update structured workspace context from JSON
# Workspace onboarding: run `/pad onboard` from an agent session inside the workspace
pad workspace members                 List workspace members
pad workspace invite <email>          Invite a workspace member
pad workspace join <code>             Accept an invitation
pad workspace export                  Export workspace data
pad workspace import <file>           Import workspace data

pad project dashboard                 Project dashboard
pad project next                      Recommended next task
pad project ready                     Query actionable next items
pad project stale                     Query stalled or attention-worthy items
pad project standup [--days N]        Daily standup report
pad project changelog [--days N]      Release notes from completed items
pad project watch                     Real-time activity stream
pad project reconcile                 Reconcile item and PR state

pad item create <coll> "title"        Create item (task, idea, plan, doc, ...)
pad item list [collection]            List items (filters: --status, --priority, --all)
pad item show <ref>                   Show item detail
pad item update <ref>                 Update item fields
pad item delete <ref>                 Delete item
pad item move <ref> <collection>      Move item between collections
pad item edit <ref>                   Open item in $EDITOR
pad item search "query"               Full-text search across all items
pad item comment <ref> "text"         Add comment to an item
pad item comments <ref>               View item comments
pad item note <ref> "summary"         Append an implementation note to an item
pad item decide <ref> "decision"      Append a decision log entry to an item
pad item block <src> <target>         Create dependency
pad item blocked-by <item> <blk>      Mark item as blocked
pad item deps <ref>                   Show dependencies
pad item unblock <src> <target>       Remove dependency
pad item related <ref>                Show direct relationships for an item
pad item implemented-by <ref>         Show incoming implementers for an item
pad item bulk-update --status X       Batch update multiple items

pad collection list                   List collections with item counts
pad collection create <name>          Create a custom collection

pad library list                      Browse convention and playbook library
pad library activate <title>          Activate a convention or playbook

pad agent install [tool]              Install /pad skill for AI coding tools
pad agent status                      Show supported tools and installation status
pad agent update                      Update installed tool integrations

pad github link [item-ref]            Link current branch's PR to item
pad github status [item-ref]          Show PR status for linked items
pad github unlink <item-ref>          Remove PR link from item

pad webhook list             List workspace webhooks
pad webhook create <url>     Create webhook

All commands accept --format json for machine-readable output and --workspace to target a specific workspace.

Authentication

Pad runs without authentication by default for frictionless local use. For local installs, pad init creates the first admin account inline. The lower-level commands are useful when you're hosting a Pad server (Docker / remote) and need to set up auth on the server host directly:

pad auth setup         # Initialize the first admin account (server host, non-local mode)
pad auth login         # Sign in
pad auth whoami        # Show current user
pad auth logout        # Sign out

Once a user exists, all API requests and web UI access require authentication. Credentials are stored in ~/.pad/credentials.json. Multiple users can be invited to workspaces with role-based access control (owner, editor, viewer).

pad workspace members               # List workspace members
pad workspace invite user@example.com
pad workspace join <code>

Architecture

┌──────────────────────────────────────────────┐
│              pad (single binary)              │
│                                               │
│  ┌──────────┐  ┌──────────┐  ┌────────────┐  │
│  │   CLI    │  │  REST    │  │  Embedded  │  │
│  │ (Cobra)  │  │  API     │  │  Web UI    │  │
│  └────┬─────┘  └────┬─────┘  │ (SvelteKit)│  │
│       │    HTTP      │        └────────────┘  │
│       └──────────────┤                        │
│                ┌─────▼─────┐                  │
│                │  SQLite   │                  │
│                │  + FTS5   │                  │
│                └───────────┘                  │
└───────────────────────────────────────────────┘
  • Go backend — chi router, SQLite via modernc.org/sqlite (pure Go, no CGO), FTS5 full-text search, SSE for real-time updates
  • SvelteKit frontend — Svelte 5, Tiptap editor, drag-and-drop, adapter-static, embedded via go:embed
  • Single binary — serves the API and web UI, runs on macOS, Linux, and Windows
  • Workspace-per-project — each project gets its own workspace linked by a .pad.toml file

All data lives in ~/.pad/pad.db. Your data. Your machine. No telemetry, no cloud, no accounts required.

Contributing

See CONTRIBUTING.md for the development guide.

make build      # Build web UI + Go binary
make test       # Run Go tests
make dev-web    # SvelteKit dev server with hot reload
make install    # Build, install to ~/.local/bin, restart server

Security

See SECURITY.md for reporting vulnerabilities.

License

Apache License 2.0

Languages
Go 64.9%
TypeScript 21.9%
Svelte 12.6%
Shell 0.3%
CSS 0.1%