3 Commits

Author	SHA1	Message	Date
xarmian	da6ce642da	feat(push): pad push — user-authored instruction dispatch to agent sessions (IDEA-2544 Phase 1) (#1090) ... * feat(push): add pad push <ref> -m vertical (IDEA-2544 Phase 1) Self-addressed, human-to-harness dispatch over the existing watch-events bus/stream: CLI -> POST .../items/{itemSlug}/push -> a new KindPush Notification (carrying the generalized TargetUserID addressed-to field KindAsk will later share) -> watchNotificationVisible delivers it back to the pushing user's own connected monitor sessions. Transient, fire-and-forget by design (no migration, no durable inbox) since assignment already covers the durable-notification case and this is meant to be the explicit, no-inference dispatch verb instead. * docs(plugin): document the push notification contract (IDEA-2544 Phase 1) Push is the one notification kind that IS an instruction rather than a passive fact, so it gets its own lead bullet in the plugin skill's notification-etiquette section (ahead of the read-only/park default, which it explicitly lifts) and a mention in the monitor's description. The embed-source skills/pad/SKILL.md has no notification section to mirror this into (the two files diverge by design) and is left untouched. * fix(push): reject over-long push messages instead of unbounded Summary Comments truncate their notification Summary to a preview (the full body is still fetchable), but a push message IS the payload — silently truncating it would corrupt the instruction with nothing to recover it from. Add maxPushMessageLen (4096, measured post-collapse) and reject anything over it with a 400 rather than truncating; state the same bound in `pad push --help` so it's discoverable before a 400, not only from one. * fix(push): close the watch-fallthrough leak, disambiguate SKILL.md exceptions Codex round 1 P1: watchNotificationVisible's push branch only returned early on a MATCH — a non-target caller fell through to the watch-map check below it, so anyone holding an unconditional (or predicated) watch on the item received every push addressed to every OTHER user, instruction text included. Push is addressed private dispatch, not an item-level fact watchers have a legitimate claim on (unlike assignment, which watchers are expected to see per `pad watch --help`) — the branch now returns unconditionally for KindPush, gating strictly on TargetUserID and never reaching the watch-map fallback either way. Pinned explicitly since Phase 4's session targeting is expected to inherit this same exclusivity. Also (codex P2): reworded the SKILL.md notification-etiquette bullets — the new push exception and the pre-existing assignment/ask exception literally contradicted each other ("the ONE narrow exception" claimed singularity after push had already claimed exception status). Now explicitly enumerated as the first and second exceptions to the never-write rule. * test(cli): pin that PushItem inherits X-Pad-Agent (BUG-2542 rebase) Verified, not assumed: PushItem builds its request via c.post -> c.newRequest like every other mutating client method (CreateWatch included), so the attribution fix's client.agentName wiring covers it for free with zero code changes needed on this branch. Adds a live httptest assertion rather than trusting the code-path read alone — the same shape as TestClientSendsResolvedAgentHeader, scoped to PushItem specifically since that's the one method this PR added. * fix(push): disambiguate workspace in the monitor line and skill contract Codex round 2 P1: the watch-events stream is user-scoped ACROSS every workspace a caller has watches in, but formatMonitorLine printed only ItemRef/Kind/Actor/Summary and dropped the Workspace field the wire payload already carried — a session linked to workspace A receiving a notification for workspace B would resolve the wrong item (or 404) with no signal in the line that anything was off. Fixed universally, not push-only: grepped plugin/ and skills/ for anything parsing "PAD ..." lines and found none — the Claude Code plugin host ingests the stdout line as free-text notification prose, formatMonitorLine's only real consumer is its own fmt.Println, so there is no wire-format consumer a workspace prefix could break. The ambiguity predates push (any watched item across workspaces already had it); push just makes the consequence sharper because it carries an instruction rather than a passive fact. SKILL.md's push bullet now tells the agent to resolve with `pad --workspace <workspace> item show <ref>` using the slug read off the notification line, not a bare `pad item show <ref>`. * fix(push): respect --format json instead of hardcoding plain text Codex round 2 P2: pushCmd's RunE ignored the global format flag and always printed "Pushed <ref>", silently discarding --format json. - server.pushResponse replaces the bare map the handler wrote before — a typed {ref, workspace, pushed, message} shape, with workspace resolved to the CANONICAL slug via s.getWorkspace (not merely echoed from whatever the URL contained), matching the same disambiguation need the round-2 P1 fix addressed for the monitor line. - cli.PushItem now returns (*PushResult, error) instead of discarding the response body. - pushCmd checks formatFlag == "json" and calls cli.PrintJSON, mirroring runCreateWatch's existing pattern. internal/cli/agent_identity_test.go's TestPushItemSendsResolvedAgentHeader needed a one-line update for PushItem's new two-value return — caught by `go vet ./...`, not `go build ./...` (which doesn't compile test files); folding vet into my own pre-flight going forward.	2026-08-13 18:41:46 -04:00
xarmian	212d59e7c6	fix(cli,server): make agent attribution actually happen (BUG-2542) (#1088) ... * fix(cli,server): make agent attribution actually happen (BUG-2542) Agent CLI writes were recorded as the human whose credentials they used. Three independent defects, each verified by reading the path AND by probing a live instance — the item deliberately held the mechanism open, so none of this is inherited. 1. THE HEADER WAS NEVER SENT. actorFromRequest sets actor="agent" on one signal: the X-Pad-Agent header. The only code that sets it took the value from `agent_name` in .pad.toml and nowhere else — no environment detection, no session detection. This repo's .pad.toml has only `workspace`, so the header has never been sent from here and every agent write has looked human. ResolveAgentName now resolves .pad.toml → $PAD_AGENT → detected runtime. 2. ITEM CREATE DISCARDED THE ACTOR. createItemChecked called actorFromRequest and kept only the source (`_, src :=`), never setting input.CreatedBy, so store.CreateItem fell through to its "user" default — even for an agent that DID send the header. Comments have always stamped it correctly; item creation silently did not, which made the skill's own contract false on its own terms. 3. SINGLE-ITEM PATCH NEVER STAMPED LastModifiedBy. Bulk ops do (handlers_items_bulk.go); the single-item path did not, so an item edited only by agents read as human-edited. Only entries VERIFIED against a live session belong in the runtime detection table, so it has exactly one: Claude Code exports CLAUDECODE=1 to child processes, confirmed by reading a pad subprocess's environment inside one. Guessing at Cursor/Windsurf/Aider variable names would put unverified claims in a shipped binary and misattribute silently when wrong; those set $PAD_AGENT until someone confirms a signature. WHAT THIS DOES NOT DO, stated in the code and the skill rather than left for someone to assume: the header is client-supplied and self-declared. An agent that omits it is indistinguishable from the human it borrows credentials from, and a human running `! pad ...` inside an agent's terminal inherits that environment and is attributed to the agent. This makes the trail HONEST, not VERIFIED — it is not a basis for machine-verifiable human-approval provenance, which needs a channel the agent cannot author at all. The incident behind this item is exactly that distinction: an agent's relay of a human's words was recorded indistinguishably from the human typing them. Contract corrected in both skill copies, since the item's first question was which of contract and behavior was wrong. It was the contract: it promised automatic agent attribution that only ever applied to workspaces that had opted in. Tests, each mutation-tested against its own defect reverted alone: - TestResolveAgentName — precedence plus the negative that makes it mean something: a plain human shell must still resolve to "". Fails 2/5 reverted. - TestItemAttribution_AgentVsHuman — agent and human legs for create, update and the create-stamp-survives-edit invariant. Fails on the create stamp reverted; fails 2/2 on the update stamp reverted. The update leg deliberately uses the OTHER writer: insertItemTx seeds last_modified_by FROM created_by, so a same-writer edit passes whether or not the PATCH stamps anything — the first version of this test did exactly that and passed its own counterfactual. Caught only because each fix was reverted separately. - TestItemAttribution_ExplicitBodyValueWins — an explicit body value still beats the header. End-to-end on a live instance through the real CLI, no .pad.toml opt-in: agent session → created_by/last_modified_by/comment all `agent`; same binary with CLAUDECODE stripped → all `user`. Claude-Session: https://claude.ai/code/session_01QGbUKZBAZoWdEgiTNWsXag * fix(server): artifact import wrote a UUID into created_by (BUG-2542) Found by Codex while reviewing the attribution fix. handleImportArtifact set `input.CreatedBy = u.ID`, which is the wrong DOMAIN for the field rather than merely the wrong value: created_by holds the role — "user" or "agent" — and consumers compare it against those literals (CommentThread.svelte, TimelineVersionCard.svelte). An imported item matched neither and rendered as neither. It also would have defeated the fix in the parent commit at this path: a non-empty CreatedBy suppresses the actor stamp, so imports would have kept a UUID while every other create path started recording the actor. The line contradicted the comment directly above it, which said Source was being left blank precisely so createItemChecked could stamp it "like every other create path". Now both fields are left blank and stamped together. The user's identity has its own home — the items.created_by_user_id column — which no create path currently populates. That is a separate gap and is not widened into this change. Claude-Session: https://claude.ai/code/session_01QGbUKZBAZoWdEgiTNWsXag * fix: close the remaining attribution bypasses Codex found (BUG-2542) Review found no P1s and three P2 families beyond the artifact-import bug already fixed in 6fac5dec. Two are closed here; two are deliberately not, and the reasons matter more than the diff. CLOSED — paths that asserted "user" and so SUPPRESSED the new stamp, which made them worse after the parent commit rather than merely stale: - cmd/pad/notes.go sent CreatedBy/LastModifiedBy = "user" from the CLIENT on all four note/decision writes. An explicit body value beats the header by design, so every agent note claimed a human wrote it, and would have kept claiming it. The client shouldn't assert an attribution it cannot know; all four now leave it to the server. - handlers_item_versions.go hardcoded LastModifiedBy "user" / Source "web" on restore, so an agent-driven restore recorded itself as a human web edit. Now stamped from the request. Also closed Codex's nit that the tests injected X-Pad-Agent directly and never proved the resolver reaches the wire — TestClientSendsResolvedAgentHeader runs the real client against an httptest server and asserts the header, with a human-shell leg asserting its ABSENCE. Fails when the client wiring is reverted. And the Source assertion now pins "web" rather than merely non-empty. NOT CLOSED, on purpose: - Collab flush. An agent PATCH stamps `agent`, then the browser's later ?source=collab-snapshot PATCH stamps `user`. Codex reads that as lost attribution; I'm not convinced it's wrong — the browser really is the writer of that flush, and the agent's edit is already recorded on the PATCH that carried it. Deciding whose name belongs on a human-flushed doc containing agent edits is a semantics call about what last_modified_by MEANS, not a bug I should settle inside a fix commit. Filed rather than guessed. - Move paths don't touch last_modified_by at all. That predates this change and is the same question (is a move an edit?), so it goes with the above. Claude-Session: https://claude.ai/code/session_01QGbUKZBAZoWdEgiTNWsXag * fix(cli): note/decision entries self-declare instead of going authorless Self-caught regression from the previous commit, found by checking the thing I changed rather than assuming it behaved like its neighbours. I removed the CLI's hardcoded CreatedBy: "user" from note and decision entries on the reasoning that applies to every OTHER write in that file: an explicit value suppresses the server's stamp, so the client should stay quiet and let the request context decide. That reasoning does not reach these two. The entries live INSIDE the item's fields JSON, which the server stores as an opaque blob and never parses for attribution — so nothing downstream fills the gap, and blanking it would have written authorless notes. Worse than the bug I was fixing: "user" was at least right half the time. They now carry cli.ActorKind() — the same self-declared signal as the header, reduced to the user/agent enum the field holds. Its doc says plainly that this is the ONE place a client should assert attribution, and why, so the next person doesn't generalise it back the wrong way. The item-level LastModifiedBy in the same functions stays server-stamped; that half of the previous commit was right. TestActorKind covers agent, explicit PAD_AGENT, and human-shell legs. Claude-Session: https://claude.ai/code/session_01QGbUKZBAZoWdEgiTNWsXag * fix(server): stamp the actor on non-parent item links (BUG-2542) Last P2 from the review. Parent links pass the actor to SetParentLink; every other link type (blocks / blocked-by / relates / implements) goes through CreateItemLink, which the CLI calls without created_by, so the store defaulted it to "user" and an agent's `pad item block` recorded a human. Same one-line shape as the create path, explicit body value still wins. TestItemLinkAttribution_AgentVsHuman covers both writers; fails on the agent leg when the stamp is reverted, control passes either way. That closes every actor-dropping path the review found except the two filed as IDEA-2549 (collab flush, move), which are semantics questions about what last_modified_by means rather than defects — Codex agrees the deferral holds if the field means content author, and flags that they become real follow-ups if we decide it means sender-of-write. Claude-Session: https://claude.ai/code/session_01QGbUKZBAZoWdEgiTNWsXag * test(server): table-drive every non-parent link type (BUG-2542) Codex nit: the link regression only covered `blocks`, and "shared routing makes the other types fine" was doing the work. It cost nothing to stop assuming, and the table earned itself on the first run — my initial list included `blocked-by`, which is CLI surface sugar that inverts source/target into a `blocks` row rather than a stored link type. The API rejects it with a 400, on BOTH writer legs, which is also how that failure reads differently from an attribution one. Now covers blocks / related / implements / supersedes / split_from against both writers. One precision fix owed on 06938079's message: it says "THE HEADER WAS NEVER SENT". Not true in general — a workspace with agent_name in .pad.toml did send it, which is exactly how I probed the behaviour before fixing it. Accurate version: the header was absent for anything that had not opted in, which is every workspace I can see, including this repo's. The body of that commit says it correctly; the headline overstates. Claude-Session: https://claude.ai/code/session_01QGbUKZBAZoWdEgiTNWsXag * style: gofmt notes.go after the attribution edit (BUG-2542) Removing the hardcoded LastModifiedBy from the two ItemUpdate literals left the surviving fields aligned to a column that no longer had a member, so gofmt disagreed and CI's golangci-lint failed the Go job in 42s. The real fault is upstream of the whitespace: my gates line for #1088 read "go test ./... green · Codex to CLEAN" and lint was simply not in it. The omission in the report and the failure in CI are the same fact — I reported a matrix that did not include the axis that broke. `make lint` runs the pinned suite CI runs and takes seconds; it belongs in every report I make, alongside test and build. Claude-Session: https://claude.ai/code/session_01QGbUKZBAZoWdEgiTNWsXag	2026-08-13 16:21:10 -04:00
xarmian	d8627968d0	feat(plugin): pad Claude Code plugin — nested layout, monitors, skills (PLAN-2469 Phase 2) (TASK-2534) (#1085) ... * feat(plugin): assemble Phase-0 scaffold v3 into a nested plugin layout — PLAN-2469 Phase 2 (TASK-2534) Drops scaffold v3 (plugin.json, marketplace.json, monitors.json, the pad/ status/capture/onboard skills) in under plugin/, verbatim, rather than at repo root. Repo root already embeds skills/pad/SKILL.md into the binary as the surface-agnostic `pad agent install` source (embed.go); loading the plugin flat at repo root would register BOTH that copy and the plugin's Claude-Code-only trimmed copy as separate skills in the same session (confirmed empirically via --plugin-dir) and would ship the whole repo as the marketplace install payload (confirmed via a real marketplace add + install + cache inspection). Nesting under plugin/ with marketplace.json's source: "./plugin" scopes both discovery and the install payload to exactly the plugin's own files, with zero content changes to the scaffold itself. The stale minimal .claude-plugin/plugin.json at repo root is removed — superseded by the real one at plugin/.claude-plugin/plugin.json; repo root's .claude-plugin/ now holds only marketplace.json, which is what `/plugin marketplace add PerpetualSoftware/pad` needs to find there. `claude plugin validate --strict` passes clean on both the repo root (marketplace) and plugin/ (plugin manifest) independently. * fix(plugin): round-1 review fixes — invocation reality, degradation ordering, confirm-by-default, license (TASK-2534) Six findings from codex round 1 + dispatcher's shallow pass: - pad/SKILL.md's "How This Works" claimed a literal `/pad <anything>` command, but under plugin namespacing this skill registers as `pad:pad`, not a bare `/pad`. Rewrote to state the true DR-1 model (contextual trigger by description, not typed) and defined the document's own `/pad <anything>` notation as shorthand for "what the user said," not literal syntax. Fixes the earlier /pad:pad cosmetic note at its root and the two "onboarding" sections that repeated the same wrong dual-syntax framing. - status/SKILL.md and capture/SKILL.md invoked `pad` before stating their missing-CLI fallback; reordered so the failure modes are handled as part of the same instruction, not an afterthought. monitors.json's command had no guard at all — a padless machine would hit a raw spawn error, not silence. Added a `command -v pad` shell guard (verified live, both branches: silent when pad is absent, invokes correctly when present) and re-verified the two original degradation legs (no .pad.toml, unreachable padd) through the exact guarded command string, not just the bare binary. - `pad bootstrap` hard-exits ("no workspace linked...") when unlinked (cmd/pad/main.go's getWorkspace()), but the skill assumed it always succeeds and the onboarding NL routing tried to load the onboard PLAYBOOK before a workspace — and therefore that playbook — could exist. Added the unlinked-workspace branch to Context Loading and taught onboarding routing to run `pad workspace init` first in that case, matching what skills/onboard/SKILL.md already did correctly. - capture/SKILL.md's "no ceremony" immediate-create contradicted the main skill's "always confirm before creating/modifying." Made confirm-first the default, with an explicit opt-out for workspaces whose conventions declare autonomous capture. - Two `open "$IMG"` examples were macOS-only; added the Linux (xdg-open) alternative and a describe-the-path fallback. - plugin.json declared MIT; the repo is Apache-2.0 (LICENSE, web/package.json). Corrected. `claude plugin validate --strict` clean on both the repo root (marketplace) and plugin/ (plugin manifest) after the fixes. * fix(plugin): make DR-4's no-write default unmistakable (TASK-2534) Second independent dogfood run found the etiquette text underdetermined behavior: one run correctly parked a context nudge, another interpreted "fold it in" as license to run pad item comments and post a real reply to the watched item — a write action from a context notification, which DR-4 never intended and the plugin's noise-discipline promise depends on never happening. Rewrote the section: read-only one-line park-and-summarize is now the explicit default for every watch notification and any addressed- to-you event the model isn't certain about; writing to Pad in reaction to a notification is called out as prohibited by name (no more "fold it in" euphemism), with a single narrow exception (an assignment/ask explicitly addressed to the session's user, where acting is unambiguously expected) and an explicit "when in doubt, park" tiebreaker. claude plugin validate --strict clean on both repo root (marketplace) and plugin/ (plugin manifest). * fix(plugin): loop the pad-missing monitor guard instead of a one-shot sleep (TASK-2534) Verifying the finding-2 guard through Claude Code's REAL monitor spawn path (--bg --plugin-dir, not a manual `sh -c` test) surfaced a real gap the manual test couldn't: the runner does NOT relaunch a monitor command after it exits. The round-1 guard (`command -v pad && exec ... || sleep 3600`) is a single check-then-sleep-then-exit — once that one hour elapses, the process exits and, per this observed behavior, is never restarted, leaving the session permanently monitor-less for the rest of its life on a machine where pad wasn't yet on PATH at session start. That silently breaks DOC-2479's "sleep-retry hourly" contract, which the Go binary's own `pad watch --stream --for-session` loop honors correctly for its two conditions (no .pad.toml, padd unreachable) via an actual internal retry loop — this shell guard needs the same shape for its one condition (pad binary absent). Wrapped the check in `while ! command -v pad; do sleep 3600; done` so it keeps re-checking indefinitely instead of dying after one interval, then falls through to the same `exec pad watch --stream --for-session` once pad becomes resolvable. Verified live through the real spawn path with a shortened sleep interval on a throwaway plugin copy: a fresh sleep child appears every cycle (confirms the loop keeps running, not one-shot), then re-verified the actual committed command (real sleep 3600) resolves a live `pad watch --stream --for-session` process when pad is present and sits in a healthy, silent, no-error `sleep 3600` loop when it's absent — both through claude --bg --plugin-dir, not manual shell invocation. claude plugin validate --strict clean on both repo root (marketplace) and plugin/ (plugin manifest). * fix(plugin): probe watch capability, not just binary existence, in the monitor guard (TASK-2534) Codex round 2, P1: the round-1 fix looped on `command -v pad`, but an old pad binary predating `pad watch` resolves on PATH fine and then dies non-zero the moment `exec pad watch --stream --for-session` runs — and the previous commit already established the runner never relaunches an exited monitor command, so that death is permanent for the session. `command -v` only proves the binary exists, not that it has the subcommand this guard needs. Changed the loop condition to `pad watch --help`, which probes the actual capability in one call: covers both missing-binary (no such command) and old-binary-without-watch (unknown subcommand, non-zero exit) with a single condition. Verified first that `--help` is safe to call as a probe — it succeeds (exit 0) with no `.pad.toml` anywhere and padd unreachable, so it can't deadlock a legitimate unlinked- project or padd-down user behind the guard. claude plugin validate --strict clean on both repo root (marketplace) and plugin/ (plugin manifest). * fix(plugin): round-2 doc fixes — capture routing, confirm scope, invocation wording, CLI accuracy (TASK-2534) Findings 2-8 from codex round 2: - capture/SKILL.md: no unlinked-workspace branch — would fail opaquely on `pad collection list` without .pad.toml. Mirrors the same routing fix the main skill already has: run `pad workspace init` first. - pad/SKILL.md's notification write-exception didn't say whether the confirm-always principle (Key Principles #3) still applies inside it. It does — the exception only lifts never-write, not confirm-first — now stated explicitly where the exception lives, same rule as capture's autonomous-capture opt-out. - The `/pad` shorthand disclaimer scoped itself to "the playbook-routing and examples sections below," missing Context Loading's "on every `/pad invocation`" a few lines above it. Widened to cover the whole document. plugin.json's own description repeated the bare "/pad conversational surface" claim; reworded to name the real typed shortcuts instead, and synced marketplace.json's plugin-entry description to match (was already a paraphrase, now identical). - Ideation example passed both `--content` and `--stdin` to the same `pad item create` call — verified --stdin wins and hangs on ReadAll with no piped input. Dropped --stdin, kept --content. - Plan-retro example was missing the mandatory `--comment` this same doc teaches elsewhere. Key Principles #2's status enumeration listed "blocked" as a task status — verified against internal/collections/templates.go: the tasks schema's actual options are open/in-progress/done/cancelled, no "blocked". Fixed both. - Two role-board pointers claimed `pad server open` lands on `/{workspace}/roles` directly; verified cmd/pad/cmd_server.go's open command only appends the workspace slug, never a sub-path. Reworded both to describe navigating to Roles from the opened UI rather than asserting an unverified deep-link. claude plugin validate --strict clean on both repo root (marketplace) and plugin/ (plugin manifest). * fix(plugin): safe (non-hanging) unlinked-workspace self-heal, onboarding offer in status, ask-events wording (TASK-2534) Codex round 3, findings 1-3: - The routing added in rounds 1-2 told the skill to run bare `pad workspace init` whenever bootstrap reported "no workspace linked." Verified live this can HANG INDEFINITELY: with pad configured (mode/URL set) but no admin account created yet / session not authenticated, `pad workspace init` calls a browser-based setup/login flow with no TTY guard and no non-interactive fallback — unlike `pad init`, which has an explicit `!canPromptForConfig()` check at the same step and fails fast with a headless-bootstrap hint instead. Bootstrap's own two failure signatures ("Pad is not configured" vs "no workspace linked") don't fully disambiguate this either — verified live that "no workspace linked" fires even when the deeper problem is "no admin account exists yet," which is exactly the state that hangs. Fixed by adding a `pad auth whoami` preflight (verified live: fast, safe, never blocks, in all three states — unconfigured, configured- but-unauthenticated, and fully set up) before ever attempting `pad workspace init`. Only self-heal when whoami reports a real user; otherwise tell the user to run `pad init` themselves in an interactive terminal (Claude Code: suggest `! pad init`). Applied consistently across pad/SKILL.md's Context Loading and Onboarding routing, onboard/SKILL.md, and capture/SKILL.md's unlinked-workspace branch (round 2 addition, same hang risk). - status/SKILL.md ran `pad project dashboard --format json` but never checked its `needs_onboarding` field (verified present on that response too, not just bootstrap's — internal/server/handlers_ dashboard.go's NeedsOnboarding), so the mandated onboarding offer couldn't fire via `/pad:status`. Added the same offer wording the main skill uses. - monitors.json's description claimed the stream delivers "asks for your role" alongside assignment; verified against internal/watchevents/watchevents.go: KindAsk is contract-reserved with no Phase 1 producer. Reworded to describe what ships today, noting ask-events as reserved-not-yet-emitted. Filed docapp TASK-2537 for the fourth finding (embed-source skills/pad/SKILL.md has the same --content/--stdin bug and has drifted from these corrections) — selective port, out of this diff's scope per the two skills' by-design framing divergence. claude plugin validate --strict clean on both repo root (marketplace) and plugin/ (plugin manifest). * fix(plugin): --full on body-promising queries, capture loads always-on conventions, onboard's already-set-up path (TASK-2534) Codex round 4, findings 1-3: - Every `pad item list conventions|playbooks --format json` example whose surrounding prose promises "bodies" was missing `--full` — verified against cmd/pad/cmd_item.go: the flag exists specifically because JSON output defaults to a token-light summary shape with no content. Without it, all 8 of these calls (the Context Loading bootstrap-field description at :41, the 7 trigger-query examples under "Before Performing Work") would return exactly what the surrounding text says they're loading bodies to avoid: metadata with no content. Added --full to all 8, not just the block the finding cited — the "Template" lines carry the identical "pull their bodies" promise as the "Concrete examples" lines a few lines below them, so leaving one set fixed and the other not would just move the inconsistency. Swept the rest of the file's `item list ... --format json` examples (Ideation load-context, Status Check role queue, Daily Standup) — left those alone; their surrounding prose asks for enumeration/counts ("3 items in your queue", "Yesterday/Today/Blockers"), not body content. The one exception found: Retrospective's task-load line promises "what shipped, what was deferred, lessons learned" — that needs actual task content to synthesize, so it got --full too, with a one-line note explaining why (the other fixed lines didn't need one; their promise was already explicit in the surrounding prose). - capture/SKILL.md never loaded conventions at all. Per the dispatcher's ruling: low ceremony means skipping bootstrap's dashboard/playbook/ role weight, not skipping mandatory project rules (trigger=always conventions exist precisely to be small and always-applied). Capture now runs the always-on conventions query (with --full) before creating and applies whatever it returns; the autonomous-capture exception now checks the SAME load instead of running its own separate (previously --full-less) query. One sentence documents the tradeoff as deliberate: always-on rules yes, full bootstrap no. - onboard/SKILL.md only defined the needs_onboarding=true branch. Added the false branch: say the workspace is already set up, summarize what exists (collection/convention counts from the bootstrap payload already in hand), and offer extend/audit instead of re-running first-time setup — same confirm-first rule as everywhere else. claude plugin validate --strict clean on both repo root (marketplace) and plugin/ (plugin manifest).	2026-08-12 23:49:47 -04:00